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ABSTRACT 


This  thesis  presents  the  detailed  design  and  implementation 
of  the  kernel  of  a  real-time,  distributed  operating  system 
for  a  microcomputer  based  multiprocessor  system. 

Process  oriented  structure,  segmented  address  spaces  and 
a  synchronization  mechanism  based  on  eventcounts  and  sequencers 
comprise  the  central  concepts  around  which  this  operating 
system  is  built. 

The  operating  system  is  hierarchically  structured,  layered 
in  three  loop  free  levels  of  abstraction  and  fundamentally 
configuration  independent.  This  design  permits  the  logical 
distribution  of  the  kernel  functions  in  the  address  space  of 
each  process  and  the  physical  distribution  of  system  code  and 
data  among  the  microcomputers.  This  physical  distribution  in 
turn,  in  a  multimicroprocessor  configuration  will  help  to 
minimize  system  bus  contention. 

The  system  particularly  supports  applications  where 
processing  is  partitioned  into  a  set  of  multiple  interacting 
asynchronous  processes.  One  such  application  is  that  of 
smart  sensor  image  processing  for  which  this  system  has  been 
specifically  developed.  The  implementation  was  developed  for 
the  INTEL  86/12A  single-board  computer  using  the  8086 
processor  chip. 
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I.  INTRODUCTION 


The  topic  of  this  thesis  is  the  detailed  design  and 
implementation  of  the  kernel  of  a  real-time,  distributed 
operating  system  for  a  multiple  microcomputer  system. 

A.  MOTIVATION 

In  the  Electro-Optics  Signal  Processing  Laboratory  at 
the  Naval  Postgraduate  School,  research  is  currently  being 
conducted  in  the  area  of  "smart  sensor  image  processing". 
Specifically  image  processing  for  long  distance  missile 
detection,  high-altitude  surveillance  and  target  acquisition 
for  tactical  missiles  is  the  topic  presently  being  investigated. 

The  smart  sensor  platform  will  require  on-board  data 
processing  of  large  quantities  of  collected  image  data. 

To  provide  the  required  "computing  power"  for  a  high 
input  data  rate  which  processes  that  data  in  "real  time",  a 
multiple  microcomputer  system  is  being  developed  capable  of 
performing  concurrent  asynchronous  computations. 

A  large  image  processing  program  can  be  partitioned  into 
small  interactive  parts.  These  will  be  dynamically  assigned 
to  the  microcomputers  available  in  the  system  for  concurrent 
"parallel"  and  "pipeline"  processing. 

If  properly  designed  and  executed,  the  concurrent  computing 
will  both  increase  the  throughput  and  decrease  the  execution 
time. 
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To  facilitate  the  dynamic  assignment  of  the  partitioned 


processes  of  a  program  for  effective  computations  by  a 
multiple  microcomputer  system,  a  real-time  distributed 
operating  system  is  needed  and  this  is  the  topic  of  the 
present  thesis. 

B.  DISCUSSION 

The  processing  power  of  microprocessors  is  increasing. 

If  this  power  can  be  effectively  coordinated  by  an  opera¬ 
ting  system,  it  would  provide  a  more  affordable  and  powerful 
product. 

The  application  of  contemporary  microprocessor  technology 
to  the  design  of  large-scale  multiple  processor  systems  offers 
many  potential  benefits.  For  example,  the  "cost"  of  high- 
power  computer  systems  could  be  reduced  drastically,  and 
"fault  tolerance"  in  critical  real-time  systems  could  be 
improved.  Designing  such  systems  presents  many  formidable 
problems  that  have  not  been  solved  by  the  singls  processor 
systems  available  today. 

The  multi-microprocessor  systems  in  use  today  suffer 
performance  degradation  as  more  processors  are  added  to  the 
system.  Sophisticated  interconnections  among  processors  and 
memories  are  needed  to  reduce  this  problem. 

Despite  the  rapidly  expanding  capabilities  of  modern 
microcomputer  systems,  they  still  are  limited  by  the 
relatively  slow  execution  speeds  of  their  microprocessors, 
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for  many  real-time  military  applications.  These  systems 
generally  do  not  provide  the  power  and  flexibility  required 
to  address  complex  and  demanding  applications.  One  such 
area  is  that  of  "real-time  digital  image  processing".  This 
is  a  particularly  demanding  application  area,  characterized 
by  the  requirement  to  apply  significant  "processing  power" 
to  a  high  input  data  rate. 

An  answer  to  the  inadequacies  of  the  single  microcomputer 
is  to  provide  for  miltiple  microcomputer  systems.  Such 
systems  could  provide  the  processing  power  necessary  to  handle 
those  applications,  which  are  presently  addressed  by  mini¬ 
computers  and  mainframe  systems.  However,  most  of  today's 
microcomputer  operating  systems  deal  only  witha  single 
processor  and  cannot  adequately  manage  multiple  processors. 

The  integration  of  large  numbers  of  relatively  inexpensive 
microcomputers  into  powerful  computer  systems  has  been  the 
subject  of  intensive  research  in  universities  and  industry 
for  several  years. 

The  primary  thrust  of  this  thesis  is  towards  a  general 
architecture  which  can  be  applied  to  hardware  systems,  that 
are  commercially  available  today  (this  project  is  currently 
using  the  INTEL  general  purpose  16-bit  8086  Microprocessor), 
with  some  custom-developed  hardware  for  intercommunication 
network  and  control. 
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C.  BACKGROUND 


The  system  software  design  uses  the  MULTICS  [9]  concepts 
of  segmentation  and  "per  process  stack",  in  conjunction  with 
Reed's  [15]  design  of  virtual  processors,  and  Reed  and 
Kanodia  [10]  eventcount  synchronization  mechanism. 

The  basic  microcomputer  operating  system  design  was 
developed  by  O'Connell  and  Richardson  [7]  and  is  based  on  the 
structure  of  a  hierarchical  kernel,  where  security  kernel  tech¬ 
nology  was  used.  O'Connell  and  Richardson  first  developed  a 
flexible  operating  system  design  that  is  fundamentally 
configuration  independent  and  adaptable  to  a  spectrum  of 
systems. 

J.  Wasson  [8] ,  in  his  thesis  defined  the  detailed  kernel 
design  of  one  member  of  the  above  family,  a  modified  real-time 
subset,  tailored  to  "real-time  image  processing"  and  applied  to 
the  INTEL  16-bit  general  purpose  8086  Microprocessor. 

The  objective  of  this  thesis  is  to  complete  the  above 
design  and  also  to  write  a  detailed  code  implementation. 

The  result  is  a  layered  loop  free  operating  system  which 
is  both  small  and  easy  to  analyze. 

The  system  supports  miltiple  asynchronous  processes,  using 
the  concept  of  "two-level  traffic  control",  to  accomplish 
"processor  multiplexing"  amongst  a  greater  number  of 
eligible  processes.  This  dual-level  "processor  multiplexing" 
design  allows  the  system  to  treat  the  two  primary  scheduling 
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decisions,  viz.,  the  scheduling  of  processes  and  the  manage¬ 
ment  of  processors,  at  two  separate  levels  of  abstraction. 

The  kernel  comprises  a  complete,  albeit  primitive, 
operating  system  providing  support  for  a  large  number  of 
asynchronous  processes. 

The  kernel  manages  all  physical  processor  resources,  and 
provides  scheduling  and  interprocess  communication  and 
synchronization  and  also  provides  the  user  with  an  execution 
environment  which  is  relatively  free  from  concern  about  the 
underlying  hardware  configuration.  The  system  is  capable  of 
performing  in  a  real-time  environment  through  the  use  of 
"preemptive  scheduling",  to  ensure  expeditious  handling  of 
time-critical  processing  requirements. 

D.  STRUCTURE  OP  THE  THESIS 

Chapter  I  presented  a  general  discussion  and  the  thesis' 
background. 

Chapter  II,  describes  the  overall  design  philosophy  of 
the  operating  system,  its  functional  requirements,  how 
multiple  processes  communicate  and  synchronize  their  tasks, 
and  finally  how  these  processes  .re  multiplexed  on  a  smaller 
set  of  processors. 

Chapter  III  describes  the  hardware  architecture  of  the 
multiprocessor  system.  The  INTEL  8086  Microprocessor  was 
chosen  for  this  implementation. 

Chapter  IV  describes  the  details  of  the  system  design. 


20 


Chapter  V  presents  conclusions  and  observations  that 
resulted  from  this  effort  and  also  suggestions  for  further 
research. 


A 
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II.  FUNDAMENTAL  DESIGN  CONCEPTS 


A.  DESIGN  PHILOSOPHY 

The  kernel  primitives  which  provide  multiprogramming 
processor  management  and  process  management,  form  one  member 
of  the  family  of  operating  systems  designed  by  O'Connell  and 
Richardson  [7] .  This  member  is  a  modified  real-time  subset. 
The  modification  consists  of  the  inclusion  of  a  more  general 
synchronization  mechanism,  eventcounts  and  sequencers  describ¬ 
ed  by  Reed  and  Kanodia  [10] ,  which  replace  the  more  tradi¬ 
tional  Signal/Wait  and  Block/Wakeup  used  in  the  original 
design. 

Before  presenting  the  details  of  this  operating  system, 
the  high  level  design  and  the  detailed  "working  implementa¬ 
tion"  of  the  system,  it  is  useful  to  investigate  the  general 
design  methodology  applied  to  the  development  of  this 
operating  system. 

Multiple  processor  systems  are  intrinsically  more  complex 
than  the  familiar  uniprocessor.  Their  complexity  has  proven 
to  be  the  major  barrier  to  realize  the  full  potential  of 
the  inherent  parallelism  available  in  such  a  system. 

One  of  the  most  important  components  of  any  computer 
system  is  the  operating  system.  The  operating  system  manages 
the  system's  resources.  Thus  system  performance  is  critically 
dependent  upon  its  effectiveness. 
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We  can  say  that  basically  two  issues  confront  the  operat¬ 
ing  system  designer.  First,  he  must  provide  system  functions 
that  support  the  services  requested  by  the  user.  These 
functional  requirements  affect  the  logical  design  of  the 
system.  Second,  he  must  address  issues  of  cost  and 
performance.  Cost  and  other  management  considerations  will 
not  be  addressed  here.  Performance  issues  concern  the 
management  of  physical  resources  and  has  to  do  with  the 
computational  speed,  and  also  system  attributes  such  as  the 
ease  of  programming,  efficiency,  correct  operation,  etc. 

There  is  a  considerable  amount  of  literature  devoted  to 
the  development  of  the  functional  design  of  operating  systems. 
Dijkstra  [12]  has  described  a  technique  for  reducing  the 
complexity  of  the  design  by  allocating  operating  system 
activities  to  a  number  of  cooperating  processes.  Process 
structure  is  simplified  in  turn,  by  defining  its  functions 
in  levels  of  increasing  abstraction,  and  by  applying  the 
principles  of  structured  programming. 

Madnick  and  Donovan  [13]  have  described  am  operating 
system  as  a  hierarchical  extended  machine.  Program  modules 
are  added  to  the  system  to  provide  many  extended  instructions, 
in  addition  to  the  hardware  instructions  available  on  the 
bare  machine.  In  complex  systems,  one  extended  machine  may 
be  constructed  upon  another  to  form  a  system  composed  of 
levels  of  abstraction  (virtual  machines)  .  Figure  1  from 
Reference  [13],  presents  the  general  idea  of  that  hierarchical 
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1 .  Memory  Management 

2.  Processor  Management 

3.  Device  Management 

4.  Information  Management 

FIGURE  1.  RELATION  OF  OPERATING  SYSTEM  TO  COMPUTER  HARDWARE 
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extended  machine  and  levels  of  abstraction  built  on  the 
bare  machine. 

Saltzer  [14]  and  Reed  [10,  15]  have  discussed  the  advan¬ 
tages  of  resource  virtualization  and  have  described  useful 
interprocess  communication  and  synchronization  mechanisms. 

The  general  design  strategies  presented  in  this  thesis 
will  aid  the  operating  system  designer  in  developing  system 
functions  in  a  clean,  logical,  verifiable  design. 

Finally,  adequate  performance  can  only  be  assured  if 
the  behavior  of  the  system  is  well  understood  and  this  in 
turn  imposes  a  strict  requirement  for  simplicity. 

In  this  design,  the  requirement  for  simplicity  is 
satisfied  by  utilizing  a  model  based  on  the  notion  of 
multiple  asychronous  processes  with  segmented  address  spaces. 
This  is  the  central  unifying  concept  which  provides  a 
straightforward  view  of  both  static  and  dynamic  system 
behavior  [4],  The  principles  of  structured  system  design 
are  also  applied  to  logically  organize  the  operating  system 
into  a  hierarchically  structured  set  of  easily  understood 
modules  whose  interactions  are  clearly  specified  and  strictly 
enforced. 

The  result  is  a  modular,  layered  operating  system  which 
makes  it  easier  to  ensure  correct  operation  and  provides 
better  opportunity  for  improving  performance  through  tuning. 
Finally,  because  the  system  is  small,  less  memory  is  used  for 
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operating  system  code  and  less  processor  time  is  spent  in 
its  execution. 

The  operating  system  design  is  logically  organized  into 
a  hierarchy  that  separates  the  user  application  processes 
from  the  kernel.  This  modular,  layered  design  lends  itself 
to  "dynamic  reconfiguration"  where  processes  can  be  relocated 
among  physical  processors  [19].  Additionally,  the  system 
initialization  technique  proposed  by  Anderson  [19]  provides  a 
basis  for  an  automatic  recovery  mechanism  that  will  initialize 
the  system  on  a  new  physical  configuration  after  the  detect¬ 
ion  of  faulty  system  components. 

B .  FUNCTIONAL  REQUIREMENTS 

The  functional  requirements  defined  below  support  the 
specific  design  goals  of  the  system  and  provide  features 
desirable  in  any  operating  system,  such  as:  a  logical  struct¬ 
ure,  fault  tolerance  and  efficiency  of  operation.  Functional 
requirements  define  services  that  must  be  provided  to  support 
the  user's  environment. 

1 .  Process  structure 

By  dividing  a  job  into  asynchronous  parts  and  execut¬ 
ing  these  parts  as  separate  entities,  significant  benefits 
can  be  realized.  Within  a  single  processor  system  the 
partitioning  into  asynchronous  parts  provides  the  "only" 
design  simplicity.  But  in  a  multi-processor  system,  the 
partitioning  into  asynchronous  parts  is  essential,  if  the 
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"parallel  and  pipeline  processing"  potential  of  the  system 
is  going  to  be  used. 

2 .  Definition  of  a  process.  Process  organization 

The  abstract  idea  of  a  process  has  been  defined 
in  several  ways.  A  simple  one  offered  by  J.  Saltzer  is 
the  following: 

"a  process  is  a  program  in  execution  on  a 
processor."  [14] 

A  process  is  the  sequence  of  actions  taken  by  some 
processor.  In  other  words,  it  can  be  viewed  as  the  past, 
present  ad  future  "history"  of  the  state  of  the  processor. 

The  notion  of  a  process  provides  a  complete  description  of 
all  instructions  executed  and  all  memory  locations  referenced 
during  the  performance  of  a  task. 

Considering  the  above  definition,  it  becomes  clear 
that  there  are  two  elements  which  together  completely 
characterize  and  define  a  given  process.  These  are  the 
process'  "address  space"  and  the  "execution  point." 

The  address  space  is  the  set  of  memory  locations  that 
could  be  accessed  during  process  execution.  The  execution 
point  is  the  state  of  the  processor  at  a  given  instant 
during  process  execution  (and  is  characterized  by  the  contents 
of  certain  processor  registers) . 

In  the  abstract  view,  an  address  space  is  defined  by 
a  collection  of  discrete  points,  each  representing  a  memory 
word.  The  process  is  described  by  the  path  traced  through 
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this  address  space  from  process  creation  to  its  destruction. 
In  Figure  2  the  main  path,  shown  by  a  heavy  black  line, 
traces  the  process  execution  point  as  it  moves  from  one 
instruction  (i.e.,  memory  word)  to  another  during  process 
execution.  The  branches  from  this  execution  point  path 
represent  data  references. 

The  concept  of  a  process  has  proven  to  be  a  funda¬ 
mental  and  powerful  one  in  the  organization  of  computer 
systems.  By  designing  a  system  as  a  collection  of  coopera¬ 
ting  processes,  system  complexity  can  be  greatly  reduced. 

This  is  because  the  asynchronous  nature  of  the  system  can  be 
structured  logically  by  representing  each  independent 
sequential  task  as  a  process  and  by  providing  interprocess 
synchronization  and  communication  mechanisms  to  prevent 
"race"  and  "deadlock"  situations  during  process  interactions. 


FIGURE  2.  PROCESS  HISTORY 
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Several  advantages  result  from  using  this  process 
oriented  design.  As  a  tool  for  dealing  with  the  asynchronous 
nature  of  system  operation,  processes  provide  a  simple, 
logical,  high-level  structure  for  the  design.  Since  each 
process  is  confined  to  a  specific  address  space,  tasks  are 
isolated  from  one  another  and  system  fault  tolerance  can  be 
improved. 

Each  process  is  assigned  a  unique  identifier  and  is 
an  explicit  entity  that  requires  management. 

In  a  "distributed"  operating  system,  those  portions 
of  the  operating  system  that  are  logically  part  of  the 
sequential  flow  of  control  (viz.,  locus  of  execution)  are 
within  the  address  space  of  each  user  process.  This  is  made 
possible  by  dividing  the  operating  system  into  procedures 
that  are  called  like  any  other  application  procedure. 

It  should  be  noted  that  in  a  distributed  operating 
system  there  is  no  "master"  assigning  processes  to  processors. 
Rather,  each  running  process  "gives  up"  its  processor  to  the 
next  process  that  is  ready  to  run. 

The  address  space  of  a  process  we  can  say,  provides 
a  container  for  the  process  which  isolates  it  from  any 
other  process.  This  eliminates  the  possibility  of  inter¬ 
process  interference  simply  because  processes  are  unable 
to  "escape"  the  confines  of  their  defined  address  spaces. 
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However,  this  is  rather  restrictive  in  that  processes 
which  are  totally  ignorant  of  each  other  have  no  hope  of 
co-operating  towards  the  accomplishment  of  some  greater  goal. 
In  order  to  mediate  this  constraint,  one  desires  to  allow 
some  restricted  (controlled)  form  of  address  space  overlap, 
(viz.,  sharing),  such  that  co-operation  is  allowed  while 
still  retaining  the  benefits  of  protection  offered  by 
isolation.  Sharing  requires  some  way  of  distinguishing  the 
shared  portions  of  the  address  space.  This  is  greatly 
facilitated  by  introducing  the  notion  of  memory  segmentation. 

Finally,  to  distinguish  between  a  process  and  a 
processor  (physical  or  virtual) ,  we  can  say  that  the  major 
difference  is  that  a  processor  is  an  "actor",  while  a  process 
is  a  sequence  of  "actions"  taken  by  that  actor.  A  process 
results  from  the  actions  of  a  processor. 

3.  Virtual  Memory  and  Segmentation 

In  many  memory  handling  schemes,  processes  cannot  run 
unless  the  entire  address  space  is  loaded  in  primary  memory. 
This  may  require  a  large  main  memory  or  it  may  restrict  the 
size  of  the  address  space.  An  alternative  plan  requires  an 
operating  system  which  manages  primary  and  secondary  memory 
to  create  the  "illusion"  of  a  memory  which  is  larger  than 
system’s  primary  memory.  Since  the  larger  memory  is  only 
an  illusion, it  is  often  called  "virtual"  storage. 

Virtual  memory  is  used  to  implement  the  concept  of  a 
"per  process"  address  space.  In  Multics  [16]  each  process  is 
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provided  with  its  own  virtual  memory  for  an  address  space. 
These  virtual  memories  are  completely  independent  of  one 
another. 

A  virtual  memory  (the  address  space  of  a  process)  is 
composed  of  a  set  of  segments.  A  segment  is  a  logical  col¬ 
lection  of  information  (e.g.,  procedure,  data  structure, 
file,  etc.)  and  is  the  basic  logical  object  of  this  design. 
Segments  are  distinct  "variable  size"  memory  objects  contain¬ 
ing  a  sequence  of  words  with  conventional  linear  addresses. 
Associated  with  a  segment  is  a  set  of  logical  attributes 
used  to  uniquely  identify  the  segment  and  to  control  access 
to  it. 

In  specifying  the  set  of  segments  that  comprise  a 
virtual  memory,  one  may  include  segments  that  are  also 
part  of  "other"  virtual  memories  as  well.  So  in  addition, 
segmentation  supports  "information  sharing"  since  a  segment 
may  belong  to  more  than  one  address  space.  Segmentation 
provides  a  means  of  associating  logical  attributes  and  labels 
with  each  segment,  such  as,  access  class,  domain,  etc.  Thus, 
segments  can  be  shared  in  a  controlled  manner  to  provide  for 
inter-process  communication  and  synchronization. 

By  using  segmentation  to  provide  a  virtual  memory 
environment,  the  user  is  presented  with  a  configuration 
independent  system  in  that  he  "sees"  a  process  address  space 
that  he  can  consider  "his  own"  and  is  not  dependent  on  the 
assignment  of  physical  addresses. 
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a.  Addressing  in  a  Segmented  System 

Addressing  in  a  segmented  memory  system  is 
"two-dimensional".  That  is,  a  complete  address  consists  of 
two  parts.  The  first  is  the  "segment  number".  This  identi¬ 
fies  the  particular  segment  of  interest.  One  attribute  of 
the  segment  is  the  physical  address  of  the  segment's  base. 

Thus  the  segment  can  be  located  anywhere  in  physical  memory 
just  by  changing  this  base  address.  The  second  dimension 
of  the  address  is  an  "offset"  relative  to  the  segment's  base 
(the  beginning  of  the  segment) .  This  serves  to  access 
specific  locations  within  the  segment. 

This  two-dimensional  addressing  "frees"  informa¬ 
tion  from  dependence  on  a  particular  memory  location  by 
making  it  arbitrarily  "relocatable". 

Figure  3  illustrates  the  two-dimensional  nature 
of  the  segment  address.  The  descriptor  segment  provides  a 
list  of  descriptors  for  all  segments  in  a  process  address 
space.  As  previously  mentioned,  one  attribute  of  the  segment, 
given  by  the  segment  descriptor,  is  the  "physical"  address 
of  the  segment's  base.  Then  the  second  dimension  needed  to 
access  a  specific  memory  word  within  this  segment  is  given 
as  an  "offset"  from  the  segment's  base,  (SEG  #  n,  OFFSET),  e.g. , 
(  1st  dimension,  2nd  dimension).  So,  in  segmented  addressing, 
each  address  is  characterized  by  an  ordered  pair  of  numbers 
(1st  dimension,  2nd  dimension). 
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Because  of  the  similarities  in  address  mapping 
hardware,  very  often  the  distinction  between  paging  and 
segmentation  is  confused.  To  distinguish  between  page  and 
segment,  we  emphasize  the  conceptual  differences  here.  The 
major  difference  is  that  a  segment  is  a  "logical"  unit  of 
information  "visible"  to  the  user's  program  and  is  of 
"arbitrary  size",  A  page  is  a  "physical"  unit  of  information 
strictly  used  for  memory  management  "invisible"  to  the  user's 
program  and  is  of  a  "fixed  size",  In  this  design  only  segmen¬ 
tation  is  supported  by  both  the  hardware  and  software. 

Segmented  memory  management  can  offer  several 
advantages.  It  can:  control  fragmentation;  facilitate  shared 
segments  (data  areas  and  procedures)  ;  and  also  for  future, 
development  in  this  system  can  provide  dynamic  linking  and 
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loading,  controlled  access,  dynamically  growing  and  shrinking 
segments.  More  details  about  segmentation  in  the  present 
design  will  be  discussed  in  the  next  chapter. 

4 .  Abstraction  -  Abstract  types 

"Abstraction"  provides  a  method  for  reducing  problem 
complexity  by  applying  a  general  solution  to  a  collection 
of  specific  cases  [17] .  Structured  programming  provides  a 
tool  for  creating  abstraction  in  software  design. 

An  "abstract  type"  is  a  class  of  objects  in  the 
system,  for  which  there  is  a  defined  set  of  operations. 

The  difference  between  an  abstract  type  and  the  "classic" 
notion  of  type,  is  that  the  user  of  an  abstract  type  need 
not  know  the  representation  of  the  object  or  the  algorithms 
used  to  implement  operations  defined  on  the  type,  and 
furthermore,  the  only  operations  allowed  to  be  performed 
on  the  object  are  specified  by  the  definition  of  the  type. 

The  concept  of  abstract  type  is  quite  attractive  for 
the  structuring  of  large  systems.  The  result  is  the  kind  of 
structuring  prescribed  by  Parnas '  "information  hiding 
principle"  [20],  for  decomposing  a  system  into  modules. 
Further,  abstract  types  fit  naturally  into  the  structure  of 
an  operating  system  since  a  major  task  of  an  operating  system 
is  to  multiplex  a  set  of  physical  resources  to  produce  a  set 
of  virtual  resources  that  can  be  viewed  as  objects  of  abstract 
type.  For  example,  this  is  exactly  what  happens  in  processor 
multiplexing  (see  paragraph  C) . 
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An  abstract  type  consists  of  a  set  of  objects  and  a 
set  of  operations.  For  example,  a  word  in  virtual  memory 
is  an  abstract  type.  Two  operations  that  can  be  carried  out 
by  instructions  in  user  processes  are  read-word,  which 
obtains  the  content  of  a  word  named  by  a  particular  virtual 
memory  address,  and  write-word,  which  takes  a  bit  string  and 
stores  it  in  the  object  specified  by  a  particular  virtual 
memory  address.  Processors,  both  real  and  virtual,  also  can 
be  viewed  as  objects  of  abstract  type. 

The  abstract  type  idea  clearly  furnishes  a  useful 
way  to  view  the  virtual  objects  seen  at  an  operating  system, 
but  for  the  design  of  an  operating  system  the  abstract  idea 
is  equally  important  in  structuring  the  internal  implementa¬ 
tion  of  the  system. 

By  strictly  applying  two  special  rules  in  addition 
to  the  general  principles  of  structured  programming,  a 
structure  consisting  of  levels  of  increasing  abstraction  can 
be  constructured. 

First,  calls  cannot  be  made  outward  toward  higher 
levels  of  abstraction.  This  frees  lower  levels  from  a 
dependence  on  higher  levels  by  creating  a  loop-free  structure 
and  results  in  a  design  which  is  capable  of  having  subsets. 

Second,  calls  to  lower  levels  must  be  made  through 
specific  entry  points  or  gates.  Each  level  of  abstraction 
creates  a  virtual  (hierarchical)  machine  [13] .  The  gate  to 
each  level  provides  a  set  of  instructions  created  for  that 
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virtual  machine.  Thus,  higher  levels  may  use  the  resources 
of  lower  levels  only  by  applying  the  instruction  set  of  a 
lower  level  machine.  Once  a  level  of  abstraction  has  been 
created,  the  details  of  its  implementation  are  no  longer  an 
issue.  Instead  users  see  layers  of  virtual  machines,  each 
defined  by  its  extended  instruction  set. 

For  this  particular  design  when  the  rules  of 
abstraction  are  applied  to  level  0,  the  physical  resources 
of  the  system,  these  resources  are  "virtualized".  Thus 
the  first  level  of  abstraction  creates  "virtual  processors", 
"virtual  memory",  and  "virtual  devices"  from  the  system1 s 
hardware.  At  each  higher  level  the  detail  of  the  design 
is  reduced.  The  gate  at  the  boundary  between  the  highest 
level  of  the  kernel  and  the  lowest  level  of  the  supervisor 
provides  a  mechanism  for  isolating  the  kernel  as  well  as 
ensuring  that  each  memory  access  is  via  kernel  software. 

This  mechanism  has  been  implemented  in  the  system  by  a  ring¬ 
crossing  mechanism  called  the  Gatekeeper  (or  Gate) . 

5 .  Protection  Domains  -  Levels  of  Abstraction 
a.  Protection  Domains 

The  implementation  of  this  operating  system  has 
not  considered  the  "internal  security"  of  the  system  but  in 
the  design  there  are  all  the  ingredients  for  future  extensions 
in  this  direction. 

An  essential  requirement  [22]  of  internal  security 
is  that  the  security  kernel  be  isolated  from  other  elements 
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of  the  system.  This  can  be  accomplished  by  the  construction 
of  protection  domains.  Protection  domains  are  used  to 
arrange  process  address  spaces  into  rings  of  different 
privilege.  This  arrangement  is  a  hierarchical  structure 
in  which  the  most  priviledged  domain  is  the  innermost  ring. 
The  structure  essentially  divides  the  address  space  into 
levels  of  abstraction  with  strictly  enforced  gates  at  the 
ring  boundaries  (Figure  4)  . 

The  protection  provided  by  the  ring  structure 
is  not  a  security  policy  (security  protection  is  implemented 
by  a  lattice  structure).  It  is,  however,  a  mechanism  to 
enforce  the  hierarchy  of  the  virtual  machine  by  creating  a 
priviledged  kernel  ring  within  the  supervisor  ring. 
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FIGURE  4.  PROTECTION  RINGS 


In  this  implementation  to  protect  kernel  proced¬ 
ures  from  the  user,  the  process'  address  space  is  divided 
into  two  hierarchical  domains,  "user  domain"  and  "kernel 
domain".  The  kernel  domain  is  the  most  priviledged.  Only 
the  kernel  executes  in  this  domain.  The  user  domain  is  less 
priviledged  and  is  separated  from  the  kernel  domain  to  protect 
the  user  from  inadvertently  causing  problems  to  the  operating 
system  services.  These  two  domains  are  generated  by  software 
since  there  is  no  hardware  support, 
b.  Levels  of  Abstraction 

Abstraction  is  a  way  of  avoiding  complexity  and 
a  tool  by  which  a  finite  piece  of  reasoning  can  cover  a 
myriad  of  cases  f 17 ] .  The  purpose  of  abstracting  is  not  to 
be  vague,  but  to  create  a  semantic  level  in  which  one  can  be 
absolutely  precise. 

Levels  of  abstraction  have  been  demonstrated  to 
be  a  powerful  design  methodology  for  complex  systems.  The 
use  of  levels  of  abstraction  in  general  leads  to  a  better 
design,  with  greater  clarity  and  fewer  errors. 

A  level  is  defined  not  only  by  the  abstraction 
that  it  supports  (for  example,  a  segmented  virtual  memory) 
but  also  by  the  resources  employed  to  realize  that 
abstraction.  Lower  levels  (closer  to  the  hardware)  are 

t 

not  aware  of  the  abstractions,  or  resources  of  lower  levels 
only  by  appealing  to  the  functions  of  the  lower  levels.  This 
pair  of  restrictions  reduces  the  number  of  interactions  among 
parts  of  a  system  and  makes  them  more  explicit. 
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Each  level  of  abstraction  creates  a  virtual 


machine  environment.  Programs  above  some  level  do  not  need 
to  know  how  the  virtual  machine  of  that  level  is  implemented. 
For  example,  if  a  level  of  abstraction  creates  sequential 
processes,  and  multiplexes  one  or  more  hardware  processors 
among  them,  then  at  higher  levels  the  number  of  physical 
processors  in. the  system  is  not  important.  This  way,  in 
present  implementation,  since  the  processes  are  assigned 
virtual  propessors  (and  not  physical) ,  there  is  no  effect 
on  the  user  when  real  processors  are  added  or  deleted 
(except,  of  course,  for  the  change  in  performance) .  Adding 
and  deleting  processors  will  have  particular  interest  when 
"fault  tolerance"  and  "fault  correction”  are  added  to  the 
attributes  of  the  operating  system. 

On  the  present  implementation,  the  operating 
system  is  structured  as  a  hierarchy  of  the  levels  of  abstrac¬ 
tion  shown  in  Figure  5. 

C.  PROCESSOR  MULTIPLEXING 

1 .  Definition  of  a  Processor 

The  basic  function  of  a  processor  is  to  perform  a 
sequence  of  operations  on  objects  in  its  environment.  The 
environment  of  a  processor  is  a  set  of  objects.  For  example, 
the  environment  of  a  physical  processor  is  that  portion  of 
memory  that  it  can  access  through  its  address  mapping  hard¬ 
ware.  Typically  the  environment  is  specified  by  an  object 
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FIGURE  5.  LEVELS  OF  ABSTRACTION 

such  as  the  "descriptor  segment "  (in  MULTICS)  which  in  turn 
names  another  object. 

A  processor  has  internal  memory,  called  its  state, 
that  it  uses  to  pass  information  from  one  operation  to  the 
next.  The  processor  determines  the  next  operation  to  perform 
by  interpreting  an  instruction  found  in  the  processor's 
environment  by  an  instruction  pointer  that  is  part  of  the 
processor  state.  Also  included  in  the  processor  state  is 
the  name  of  the  current  domain  in  which  the  processor  is 
executing. 

Each  operation  performed  may  modify  the  contents 
of  the  processor's  internal  memory.  In  particular,  it  changes 
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the  instruction  pointer  to  select  the  next  instruction  to 
be  interpreted. 

As  an  object  of  abstract  type,  a  processor  may  be 
part  of  the  environment  of  other  processors.  The  operations 
that  can  be  performed  on  a  processor  object  are:  loading 
a  new  state  into  the  processor,  extracting  the  current  state 
from  the  processor,  causing  the  processor  to  run,  causing 
the  processor  to  stop,  etc. 

A  processor  can  be  a  physical  object  such  as  the 
INTEL  8086,  16-bit  general-purpose  microprocessor  used  to 
implement  this  design.  In  this  case,  the  processor  registers 
comprise  the  state  of  the  processor.  The  environment  of  the 
processor  includes  all  of  the  primary  memory  that  is  acces¬ 
sible  through  the  processor's  descriptor  segment.  The 
descriptor  segment  in  this  design  is  related  to  the  four 
hardware  segment  registers  (CS,  DS,  SS  and  ES) .  Details 
are  discussed  in  the  next  chapter. 

On  the  other  hand,  a  virtual  processor  which  has 
no  direct  hardware  manifestation,  is  a  simulation  of  a 
physical  processor  achieved  by  using  physical  processors 
to  interpret  the  instructions  to  be  executed  by  the  virtual 
processor.  The  virtual  processor  idea  is  discussed  in  the 
following  paragraph  3. 

2 .  Definition  of  Processor  Multiplexing 

Multiplexing  can  be  defined  as  the  use  of  a  single 
resource  for  different  purposes  at  different  times.  For 
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example,  the  physical  bus  lines  can  be  used  both  for  addresses 
and  data  during  different  times  of  a  machine  cycle. 

Processor  multiplexing  is  a  technique  for  sharing 
scarce  processor  resources  among  a  number  of  processes.  The 
ability  to  multiplex  processors  efficiently  provides  a 
mechanism  for  the  virtualization  of  these  physical  processors 
by  simulating  the  existence  of  a  larger  number  of  virtual 
processors.  This  technique  is  widely  used  in  conventional 
uniprocessor  systems  where  it  is  called  multiprogramming.  It 
seeks  to  maximize  the  use  of  the  available  hardware  by  auto¬ 
mating  control  of  process  loading  and  execution.  It  also 
greatly  increases  the  flexibility  of  a  system  allowing  it 
to  be  effective  in  more  complex  and  demanding  applications. 

J.  H.  Saltzer  [14]  presented  one  of  the  fundamental 
works  on  the  subject  of  processor  multiplexing. 

3.  Processor  Virtualization 

The  first  levels  of  abstraction,  above  system  hard¬ 
ware,  creates  virtual  representations  of  physical  resources 
(virtual  processors,  virtual  memory).  Since  upper  levels  of 
the  design  operate  on  these  virtual  processors  rather  than 
on  physical  processors,  most  of  the  design  (i.e.,  everything 
above  virtualization  level)  is  independent  of  the  physical 
configuration  of  the  system.  This  means  that  by  providing 
the  virtual  to  real  processor  binding  in  the  kernel  of  the 
operating  system  and  since  the  processes  are  assigned  virtual 
processors  (and  not  real  processors) ,  there  is  no  effect 


42 


on  the  user  when  real  processors  are  added  or  deleted  in  the 
system  (except,  of  course,  for  the  change  in  performance). 

The  physical  processor  resources  (those  hardware 
devices  that  execute  machine  instructions)  are  virtualized 
by  creating  abstract  processors  called  virtual  processors. 

Processor  multiplexing  can  be  defined  also  as  a 
simulation  of  a  number  of  distinct  virtual  processors  by  a 
smaller  number  of  real  processors, 
a.  Virtual  Processors 

A  virtual  processor  is  a  data  structure  that 
contains  a  complete  description  of  a  process  in  execution  on 
a  physical  processor,  at  a  given  instant.  This  description 
is  contained  in  the  process  execution  point.  The  address 
space  of  the  process  must  be  accessible  to  the  virtual 
processor  when  it  is  "loaded"  on  ("bound"  to)  a  CPCJ.  To 
provide  a  useful  virtualization  capability,  the  CPU  must 
have  the  ability  to  efficiently  multiplex  process  execution 
points  and  address  spaces  (i.e.,  it  must  support 
multiprogramming) . 

Virtual  processors  are  simulations  of  processors. 
They  can  be  viewed  in  essentially  the  same  way  as  physical 
processors,  in  that  they  execute  the  same  instructions. 
However,  the  instruction  set  of  a  virtual  processor  has  been 
expanded  to  include  some  instructions  which  the  physical 
processors  do  not  directly  have.  These  include  "instructions" 
to  "load"  a  process,  certain  operation  called  interprocess 
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communication  and  synchronization  primitives,  system  service 
calls,  etc. 

For  example,  the  AWAIT  operation  is  not  an 
operation  that  requires  real  processor  resources,  it  is 
rather  an  operation  that  inhibits  use  of  real  processor 
resources  by  the  virtual  processor. 

Virtual  processors  exist  only  as  "abstract" 
processors  represented  by  a  data  structure.  They  are  used 
as  the  vehicle  for  the  control  and  manipulation  of  processor 
resources. 

Each  of  the  virtual  processors  executes  a  sequence 
of  operations  in  time.  These  sequences  are  actually 
performed  by  the  real  processors.  Successive  operations  of 
the  same  virtual  processor  may  be  separated  by  a  gap  of 
time,  during  which  operations  of  another  virtual  processor 
are  being  executed  by  the  real  processors.  Figure  6  shows 
how  the  operations  of  three  virtual  processors  might  be 
mapped  into  the  operation  sequence  of  one  real  processor 
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FIGURE  6.  MULTIPLEXING  A  REAL  PROCESSOR 
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To  define  a  term  used  frequently  in  this  thesis, 
a  virtual  processor  being  simulated  by  a  real  processor  is 
"bound"  to  that  real  processor  whenever  its  process  is 
being  executed  by  the  real  processor.  Thus,  Virtual  Proces¬ 
sor  #2  in  Figure  6  is  bound  to  Real  Processor  #1  during  the 
first  time  interval. 

Processor  multiplexing  also  requires  a  policy  of 
scheduling.  Given  a  number  of  virtual  processors  to  which  a 
real  processor  may  be  bound  at  any  one  time,  the  real 
processor  can  execute  only  one  virtual  processor.  The 
choice  of  the  processor  to  run  is  made  by  some  algorithm 
called  virtual  processor  scheduler.  This  algorithm  receives 
as  input  the  set  of  virtual  processors  belonging  to  this 
real  processor  and  chooses  which  one  is  to  run  (be  bound  and 
execute) . 

4.  Multiprogramming 

Multiprogramming  is  used  to  improve  system  efficiency 
and  to  create  a  virtual  environment  which  frees  the  remainder 
of  the  operating  system  from  a  dependence  on  the  physical 
processor  configuration.  Processor  management  provides  a 
means  of  coordinating  the  interaction  of  the  asynchronous 
processes  which  comprise  the  system.  This  implementation 
employs  a  processor  multiplexing  technique  for  a  distributed 
kernel  and  provides  a  virtual  interrupt  mechanism.  The 
modular  hierarchical  structure  of  the  software  is  "loop-free" 
to  support  future  system  expansion  to  higher  level  functions. 
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The  clean,  logical,  process-oriented  structure  of  the 
system  offers  other  benefits  as  well,  including  possible 
inclusion  of  rault  tolerance,  resource  configuration 

independence,  and  efficiency. 

In  a  system  where  there  are  more  processes  than 

processors,  there  must  exist  a  means  of  switching  processors 
from  process  to  process.  For  example,  reasons  for  switching 
processes  are:  current  process  completes,  current  process 
is  blocked,  a  higher  priority  process  is  ready  to  run,  etc. 

Whatever  the  reason  for  switching,  there  are  certain 
tasks  that  must  be  done  in  performing  the  switch.  First, 
save  the  address  space  and  current  execution  point  of  the 
old  process.  Secondly,  load  the  address  space  and  the 
execution  point  of  the  new  process. 

5.  Multiprocessing 

The  process  structure  provides  the  essentials  for 
parallel  processing.  That  is  the  support  for  a  set  of 
asynchronous  processes  which  can  communicate  with  each  other. 
Parallel  processing  does  not  require  a  multiprocessor 
environment.  However,  in  a  multiprocessor  environment, 
parallel  processing  can  provide  faster  completion  of  a  job. 

Whenever  a  job  depends  on  a  mixture  of  asynchronous 
and  synchronous  tasks  and  time  is  a  factor,  then  concurrent 
processing  is  a  possible  solution  to  get  the  job  done  in 
the  specified  amount  of  time.  Using  several  processors 
working  on  the  same  job  and  each  of  them  doing  separate  tasks, 
the  overall  time  required  to  to  this  job  can  be  reduced  (job 

has  been  structured  into  explicit  processes) . 
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The  above  discussion  provides  some  of  the  major 
reasons  why  this  system  was  designed  to  support  parallel 


processing  on  multiple  processors. 

6 .  Two-Level  Processor  Multiplexing 

In  this  design  there  are  two  levels  of  processor 
multiplexing.  The  design  in  two  levels  arose  from  the 
existence  of  multiple  physical  processors.  Each  of  the 
levels  addresses  a  distinct  requirement.  One  level  supports 
virtual  processor  management,  that  is,  the  provision  of 
inter-process  communication  and  synchronization.  The 
other  supports  the  management  of  physical  resources  by  the 
operating  system.  The  first  one  addresses  the  multiplexing 
of  virtual  processors  among  processes  and  is  the  "Traffic 
Controller".  The  other  addresses  the  multiplexing  of 
physical  processors  among  virtual  processors  and  is  the 
"Inner  Traffic  Controller". 

a.  The  Traffic  Controller 

The  Traffic  Controller  represents  the  upper 
level  of  processor  multiplexing  (Level  2)  and  provides  the 
mechanism  for  multiplexing  virtual  processors  among  processes. 
Thus  it  is  responsible  for  inter-process  synchronization  and 
communication. 

As  an  example,  consider  that  a  Process  A  wishes 
to  synchronize  its  actions  with  another  Process,  B,  such 
that  Process  B  has  to  complete  some  task  before  A  can 
continue  execution.  Thus  A  will  execute  to  the  point  where 
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it  cannot  proceed  further  and  then  wishes  to  signal  B. 

When  Process  B  has  finished  that  task  it  must  notify  Process 
A  of  its  completion  so  that  Process  A  may  then  proceed. 

This  inter-process  synchronization  and  communica¬ 
tion  is  handled  at  the  level  of  the  Traffic  Controller.  In 
the  above  example,  when  Process  A  discovered  that  it  could 
not  proceed  further,  it  "gave  away"  its  virtual  processor  to 
another  process  that  could  be  run.  In  this  way  the  Traffic 
Controller  suspended  the  execution  of  Process  A  and  a  new 
process  was  bound  to  its  virtual  processor.  In  the  same 
way,  when  B  completes  (viz.,  it  has  no  more  work  to  perform) 
it  will  also  give  its  virtual  processor  away, 
b.  The  Inner  Traffic  Controller 

The  Inner  Traffic  Controller  comprises  the 
lower  level  of  processor  multiplexing  (Level  1)  and  provides 
the  second  set  of  multiplexing  functions.  It  multiplexes 
physical  processors  among  a  fixed  set  of  virtual  processors. 
In  particular,  the  system's  interrupt  structure  is  managed 
by  the  Inner  Traffic  Controller. 

If  a  user  process  calls  upon  some  system  service, 
such  as  disk  I/O  or  I/O  for  a  real-time  sensor,  it  must  wait 
for  that  service  to  be  completed  before  it  can  proceed.  The 
performance  of  a  system  service  is  considered  to  be  part  of 
the  requesting  processes.  However,  the  service  may  actually 
be  supported  by  another  virtual  processor.  To  control  this 
interaction,  the  Inner  Traffic  Controller  provides  the 


required  inter-virtual  processor  synchronization  and  communi¬ 
cation  mechanism.  In  particular,  a  physical  system  interrupt 
is  directly  transformed  into  a  synchronization  signal  to  a 
wait  mu  virtual  processor.  This  structure  is  particularly 
.-pc:tant  for  the  support  of  real-time  processing,  and  note 
•it  . *  is  completely  distinct  from  inter-process  synchroni- 
•  .•  .  r  r,1  communication  described  in  paragraph  6a. 
processor  Multiplexing  Strategy 
i.  Process  State  Transitions 

Figure  7  illustrates  the  state  transitions  of 
a  set  of  processes  as  a  virtual  processor  is  multiplexed 
imonq  them.  Some  eligible  process  (one  which  is  in  the  ready 
state)  is  scheduled  to  run  and  is  "bound"  to  the  virtual 
processor.  At  this  time,  the  process  makes  the  transition 
to  the  running  state.  As  far  as  the  process  is  concerned, 
once  it  enters  the  running  state,  it  is  executing. 

At  some  point  in  its  execution,  the  process  may 
desire  to  block  itself  or  signal  another  process.  (For 
example,  when  Process  A  is  at  that  execution  point  and  needs 
data  computed  by  another  Process,  B. )  In  that  case,  it  will 
block  itself  (will  enter  the  blocked  state)  and  will  "give 
up"  the  virtual  processor  to  which  it  is  presently  bound  and 
will  be  out  of  "contention"  for  processor  resources.  It  will 
remain  in  the  blocked  state  until  some  other  process  will 
signal  it.  (In  the  above  example,  when  Process  B  has  computed 
the  needed  data,  for  Process  A. )  Then  this  process  will  make 
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STATES:  READY,  RUNNING,  BLOCKED 

TRANSITION  1:  Decided  by  the  Traffic  Controller  scheduler 
(higher  priority  ready  process) 

TRANSITION  2:  After  a  Traffic  Controller  AWAIT  operation. 

TRANSITION  3:  After  a  Traffic  Controller  ADVANCE  operation. 

TRANSITION  4:  After  a  Traffic  Controller  ADVANCE  operation 

(and  effect  of  preemptive  scheduling) . 


FIGURE  7.  PROCESS  STATE  TRANSITIONS 
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the  transition  back  to  the  ready  state.  If  the  process 
signals  other  processes,  it  will  make  a  transition  from  the 
running  state  back  to  the  ready  state  from  which  it  may  be 
scheduled  to  run  again.  In  doing  so,  it  allows  the  Traffic 
Controller  to  possibly  give  the  virtual  processor  to  some 
other  higher  priority  process  which  may  be  ready  to  run. 

The  mechanisms  which  decide  and  permit  these 
transitions  are  the  Traffic  Controller  Scheduler  and  the 
Traffic  Controller  inter-process  synchronization  and  communi¬ 
cation  primitives  AWAIT,  ADVANCE.  Their  details  will  be 
discussed  in  Chapter  IV. 

b.  Virtual  Processor  State  Transitions 

Figure  8  illustrates  the  state  transitions  made 
by  the  virtual  processors  as  a  physical  processor  is 
multiplexed.  This  diagram  is  very  similar  to  that  of  Figure 
7.  However,  these  transitions  are  not  directly  observable 
by  processes  except  in  the  differences  of  their  execution 
times,  as  virtual  processor  state  transitions  result  from 
the  management  of  physical  resources  by  the  operating 
system. 

A  running  virtual  processor  can  make  a  transition 
to  the  waiting  state  or  to  the  ready  state.  The  transition  to 
the  waiting  state  occurs  when  a  virtual  processor  must  wait 
for  the  completion  of  some  system  service  (analogous  to  the 
blocking  of  Process  A  in  the  example  given  in  paragraph  a) . 

The  transition  from  running  state  back  to  ready  state  occurs 
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STATES:  READY,  RUNNING,  WAITING 


TRANSITION  1:  Decided  by  the  Inner  Traffic  Controller 
scheduler. 

TRANSITION  2:  After  an  Inner  Traffic  Controller  AWAIT 
operation. 

TRANSITION  3:  After  an  Inner  Traffic  Controller  ADVANCE 
operation. 

TRANSITION  4:  After  an  Inner  Traffic  Controller  ADVANCE 
operation. 


FIGURE  8.  VIRTUAL < PROCESSOR  STATE  TRANSITIONS 
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when  the  running  virtual  processor  signals  other  virtual 
processors.  It  will  allow  the  Inner  Traffic  Controller  to 
possibly  run  another  higher  priority  virtual  processor. 

While  in  the  waiting  state,  the  virtual  processor  is  out  of 
"contention"  for  processor  resources  until  another  virtual 
processor  signals  it  to  continue.  While  in  the  ready  state, 
the  virtual  processor  is  in  contention  for  processor  resources 
and  so  may  be  scheduled  to  run  on  the  physical  processor. 

The  mechanisms  which  decide  and  permit  these 
transitions  are  the  Inner  Traffic  Controller  scheduler  and 
the  Inner  Traffic  Controller  inter-virtual  processor  synchro¬ 
nization  and  communication  primitives  AWAIT,  ADVANCE.  Their 
details  will  be  discussed  in  Chapter  IV. 

D.  COMMUNICATION  AND  SYNCHRONIZATION 

For  concurrent  processing,  a  job  that  is  composed  of 
sequential  and  non-sequential  tasks  is  explicitly  divided 
into  an  appropriate  structure  of  processes  that  can  run 
concurrently.  Inter-process  communication  and  synchroniza¬ 
tion  are  necessary  for  concurrent  processing. 

It  is  the  responsibility  of  the  operating  system  to 
provide  mechanisms  for  communication  between  cooperating 
processes.  There  are  two  different  kinds  of  communication 
that  processes  must  be  able  to  achieve. 

There  must  exist  a  way  for  processes  to  exchange  data 
in  some  way.  This  mode  of  communication  is  called  inter¬ 
process  communication. 
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There  must  also  exist  a  way  for  processes  to  wait  for 
data  prepared  by  other  processes,  and  for  processes  that 
prepare  such  data,  to  signal  that  this  data  is  available. 

This  interaction  is  different  than  communication  of  data, 
and  is  called  inter-process  synchronization.  Together  these 
two  modes  are  called  inter-process  communication  and 
synchronization. 

The  actual  coordination  for  the  exchange  of  data  between 
processes  is  realized  by  the  use  of  "shared  writable"  segments. 

Therefore,  to  utilize  the  parallelism  and  pipelining 
afforded  by  multiple  processors,  a  mechanism  is  required  for 
inter-process  communication  and  synchronization.  It  is  used 
for  controlling  the  execution  of  processes  and  coordinating 
the  sharing  of  data. 

The  most  widely  used  synchronization  primitives  are 
Dijkstra's  semaphores  [11]  or  Saltzer's  Block  and  Wakeup  [14] 
that  were  used  in  O'Connell  and  Richardson's  original 
design  [7].  However,  the  design  decision  was  made  to  use 
a  different  mechanism  which  provides  automatic  "broadcasting", 
supports  "parallel  signalling"  and  addresses  the  questions  of 
"confinement"  (or  *  property)  in  a  secure  system.  This  is  the 
synchronization  mechanism  based  on  the  design  of  eventcounts 
and  sequencers  of  Reed  and  Kanodia  [10], 

The  synchronization  between  processes  is  supported  by 
the  AWAIT  and  ADVANCE,  that  are  the  kernel  calls  to  the 
Traffic  Controller  level.  The  Traffic  Controller  is  the 
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kernel  module  that  manages  processes  and  supports  scheduling 
for  user  processes  by  multiplexing  the  user  processes  into 
a  limited  (fixed)  number  of  virtual  processors. 

AWAIT  and  ADVANCE  are  primitives  of  the  Traffic 
Controller.  These  primitives  can  be  used  to  provide  simple 
cooperation,  such  as  mutual  exclusion  or  complex  inter¬ 
actions,  when  required  by  the  application.  How  the  user's 
procedures  invoke  the  AWAIT  and  ADVANCE  primitives  depends, 
of  course,  on  the  actual  process  structure.  (Examples  will 
be  given  in  Appendix  A) . 

A  process  can  only  block  itself  (using  AWAIT)  and  cannot 
block  another  process.  The  AWAIT  sets  the  "calling  process" 
that  invoked  AWAIT  in  the  blocked  or  ready  state  and  then 
the  Traffic  Controller  Scheduler  schedules  another  ready 
process  to  run,  the  highest  priority  ready  process. 

The  ADVANCE  is  used  to  provide  asynchronous  processes 
with  a  synchronization  signal.  The  ADVANCE  takes  as  parameter 
the  name  of  the  associated  eventcount.  It  advances  the  value 
of  that  eventcount  by  one.  This  incrementation  of  the  even- 
count  value  is  "broadcast"  to  all  the  processes  waiting  for 
that  event.  Then  a  check  is  made  to  determine  if  the  awaited 
eventcount  value  (for  the  processes  waiting  that  event)  is 
smaller  or  equal  to  the  current  value  of  the  eventcount.  If 
this  is  the  case,  then  these  previously  blocked  processes 
will  awake  and  resume  the  ready  state.  Otherwise  they  will 
remain  blocked.  Then  a  check  is  made  to  find  out  if  the 
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currently  running  process  is  of  lower  priority  than  the  other 
ready  processes  (after  ADVANCE  operation) .  If  that  is 
the  case,  the  ADVANCE  will  send  to  the  virtual  processor 
(which  is  running  this  lower  priority  process)  a  "pre-empt 
interrupt”.  Finally  the  scheduler  will  select  the  highest 
priority  ready  process  to  run.  So,  we  see  that  the  ADVANCE 
is  also  responsible  for  operating  the  "pre-emption 
mechanism" . 

The  above  describes  roughly  the  idea  of  AWAIT  and 
ADVANCE  primitives,  which  are  very  close  to  the  BLOCK  and 
WAKEUP  described  in  O'Connell  and  Richardson's  thesis  [7]. 

More  details  and  the  whole  operation  of  eventcounting  will 
be  discussed  in  Chapter  IV. 

Another  system  level  concerned  with  synchronization  is 
the  Inner  Traffic  Controller.  This  level  manages  the  physical 
(real)  processors  to  create  the  virtual  processors,  that  are 
in  turn  managed  by  the  Traffic  Controller. 

The  Inner  Traffic  Controller  provides  the  interface  and 
does  the  multiplexing  among  the  physical  (real)  and  virtual 
processors.  Each  physical  processor  has  associated  with  it 
several  (a  fixed  number)  of  virtual  processors.  Some  of 
these  virtual  processors  are  mutliplexed  in  turn  by  the 
Traffic  Controller  among  user  processes.  Each  system  process 
is  assigned  (dedicated  to)  a  virtual  processor.  In  the  current 
implementation  there  are  two  such  processes,  and  these  will 
be  discussed  in  Chapter  IV. 
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The  Inner  Traffic  Controller  decides  which  virtual 
processor  will  run  on  the  physical  processor,  based  on  the 
priority  assigned  to  each  virtual  processor.  Of  course 
from  the  number  of  virtual  processors  assigned  to  a  real 
processor  only  one  can  run  on  it  at  a  time.  The  primitives 
ITC$AWAIT  (Inner  Traffic  Controller  AWAIT)  and  ITC$ADVANCE 
(Inner  Traffic  Controller  ADVANCE)  are  used  to  provide 
communication  and  synchronization  among  the  virtual 
processors.  These  primitives  are  very  similar  in  form 
and  function  to  the  AWAIT  and  ADVANCE  of  the  Traffic 
Controller. 
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III.  MULTIPROCESSOR  ARCHITECTURE 


The  manifestation  of  an  operating  system  design  is,  of 
course,  software  in  execution  on  a  system  of  equipment.  If 
the  equipment  must  be  selected  early  in  the  design,  care 
must  be  taken  to  insure  that  the  overall  system  design  goals 
are  compatible  with  the  actual  hardware  capabilities.  On  the 
other  hand,  if  specific  design  goals  must  be  met,  then  actual 
hardware  selection  could  be  made  late  in  the  design  process. 
Then,  even  if  a  hardware  change  must  be  made,  the  penalty  for 
correcting  it  will  be  small,  since  only  the  lowest  level  of 
the  design  (where  resources  are  virtualized) ,  need  be  changed. 

The  particular  hardware  selected  for  this  implementation, 
is  based  on  the  INTEL  86/12A  single  board  microcomputer  [2] . 

A.  HARDWARE  REQUIREMENTS 

One  of  the  principal  design  goals  of  the  system  design 
is  to  provide  for  configuration  independence.  That  is  when 
real  processors  are  added  or  deleted  the  system  will  continue 
to  function  except  of  course  for  some  change  in  performance. 
Therefore,  the  operating  system  imposes  only  a  few  constraints 
on  the  hardware,  that  are  noted  below: 

1.  Shared  Global  Memory 

The  operating  system  maintains,  "system-wide  control 
data"  accessible  to  each  of  the  processors  via  "shared" 
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segments.  The  communication  path  utilized  for  sharing  this 
data  is  shared  memory.  Thus  some  shared  memory  must  be  made 
available  to  each  microcomputer  in  such  a  way  as  to  allow 
independent  access  at  the  level  of  single  memory  references. 

(a  very  small  part,  of  a  separate  memory  board  (MUPRO)  is  used 
as  shared  global  memory,  in  this  system  implementation) . 

2.  Multiprocessor  Synchronization  Support 

There  must  also  exist  some  "hardware-supported  multi¬ 
processor  synchronization  primitive".  This  can  be  any  form 
of  an  indivisible  read-alter-rewrite  memory  reference.  This 
capability  is  required,  to  implement  the  global  locks  on 
shared  data  to  prevent  race  conditions,  as  the  physical  pro¬ 
cessors  attempt  to  asynchronously  manipulate  shared  data. 

For  better  understanding  of  this  and  the  previous  paragraph, 
consider  the  following  cases  of  APT  and  VPM.  Two  of  the 
system-wide  data  control  tables  are  the  VPM  (Virtual  Processor 
Mapping)  and  the  APT  (Active  Process  Table) ,  as  shown  in 
Figure  9.  VPM  is  the  principal  central  data  base  for  the  Inner 
Traffic  Controller  which  contains  entries  for  all  of  the 
virtual  processors  in  the  system.  Each  entry  (there  is  one 
"per  virtual  processor")  has  several  fields,  such  as  the 
virtual  processor  state,  priority,  etc.,  which  will  be 
described  in  Chapter  IV. 

Making  this  table  globally  available  facilitates 
communication  among  virtual  processors  at  the  Inner  Traffic 
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APT:  ACTIVE  PROCESS  TABLE 
VPM:  VIRTUAL  PROCESSOR  MAP 
SBC:  SINGLE  BOARD  COMPUTER 

MMGT:  MEMORY  MANAGEMENT  PROCESS 

IDLE :  IDLE  PROCESS 


FIGURE  9.  GLOBAL  LOCKS  ON  SHARED  CONTROL  DATA 
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Controller  level,  on  a  "system-wide"  scale,  since  every 
virtual  processor  can  access  this  table. 

But  to  prevent  race  conditions,  and  also  to  assure 
that  only  one  processor,  at  a  time,  accesses  the  VPM,  as  the 
physical  processors  attempt  to  asynchronously  manipulate 
shared  data,  we  see  the  need  of  a  global  lock  for  VPM  table. 

So  in  the  implementation  (coding) ,  every  time  the  VPM  is 
accessed  either  to  read  data  or  to  write,  e.g.  update  a 
field,  conceptually  a  "key"  is  turned  and  the  VPM  table  is 
locked.  When  the  access  task  is  finished,  before  leaving 
we  unlock  the  VPM. 

Exactly  the  same  concept  is  applied  for  the  APT, 
which  is  the  principal  central  data  base  for  Traffic 
Controller  in  LEVEL  2,  containing  entries  for  every  process. 

In  the  implementation  of  this  design  (coding) ,  we 
can  see  that  modules  accessing  VPM,  as  for  example,  ITCSAWAIT 
and  ITC$ADVANCE,  and  also  modules  accessing  APT,  as  TC$AWAIT, 

TC$ ADVANCE  and  TC$PE$HANDLER  (Traffic  Controller  Preempt  Hand¬ 
ler)  ,  lock  and  afterwards  unlock  the  corresponding  global  table. 

To  set  these  global  locks,  the  implementation  of  the 
present  design  utilizes  the  "test-and-set  semaphore"  oper¬ 
ation.  This  mechanism,  supported  by  the  PL/M  built-in 
procedure  "Lockset"  [1] ,  is  a  spin-lock  with  potentially 
significant  impact  on  system  bus  traffic. 
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3.  Inter-Processor  Communication 


Finally,  some  method  of  communication  between  physical 
processors  must  be  provided.  This  is  satisfied  by  an  ability 
to  generate  interrupts  between  the  physical  processors.  This 
capability  is  required  for  the  implementation  of  "Preemptive 
scheduling"  and  is  supported  by  the  INTEL  SBC  86/12A  using  a 
specific  hardware  configuration  and  software  control. 

B.  HARDWARE  CONFIGURATION 

1.  System  Configuration 

The  hardware  system  is  configured  as  a  multi¬ 
processor  [18].  It  consists  of  a  number  of  single  board 
microcomputers  and  a  global  memory  module,  connected  by  a 
single  shared  bus.  The  system  differs  from  conventional 
multiprocessors  in  that  each  of  the  microcomputers  possesses 
its  own  local  memory.  The  global  memory  module  is  connected 
directly  to  the  system  bus,  and  is  the  only  physical  shared 
memory  resource  by  all  of  the  processors.  The  general  con¬ 
figuration  is  shown  schematically  in  Figure  10. 

2 .  Specific  Hardware  Employed 

The  particular  hardware  selected  for  this  implemen¬ 
tation  is  based  on  the  INTEL  86/12A  single  board  micro¬ 
computer  [2],  This  microcomputer  utilizes  the  INTEL  8086 
16-bit  microprocessor  capable  of  directly  addressing  a  total 
of  1  Mega-byte  of  physical  memory. 
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FIGURE  10.  MULTIPROCESSOR  CONFIGURATION 


63 


a.  The  8086  Microprocessor 

The  8086  microprocessor  is  suitable  for  a  wide 
spectrum  of  microcomputer  applications.  Systems  using  8086 
can  range  from  uniprocessor  minimal -memory  designs,  to  multi¬ 
processor  systems  with  up  to  several  Megabytes  of  memory. 

The  CPU  is  designed  to  operate  with  the  8089 
input/output  processor  and  other  processors  in  multi¬ 
processing  and  distributed  processing  systems.  Built-in 
coordinating  signals  and  instructions,  and  also  electrical 
compatibility  with  INTEL'S  MULTIBUS  shared  bus  architecture, 
support  the  development  of  multiple-processors  design. 

Actual  performance,  of  course,  varies  from  appli¬ 
cation  to  application.  But  in  comparison  to  the  8-bit  2-MHZ 
8080A,  8086  is  seven  to  ten  times  more  powerful.  The  high 
performance  of  the  8086  is  realized  by  combining  a  16-bit 
internal  data  path  with  a  pipelined  architecture  that  allows 
instructions  to  be  prefetched  during  unused  bus  cycles. 
Furthermore  software  for  high-performance  8086  systems  need 
not  be  written  in  assembly  language.  The  CPU  is  designed  to 
provide  direct  hardware  support  for  programs  written  in  high- 
level  languages,  such  as  INTEL'S  PL/M-86  which  is  used  for 
the  implementation  of  this  operating  system  design. 

The  8086  instruction  set  supports  direct  oper¬ 
ation  on  memory  operands,  including  operands  on  the  stack. 

The  hardware  addressing  modes  provide  straightforward 
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implementations  of  based  variables,  arrays,  arrays  of 
structures,  character  data  manipulation  (there  is  an  exten¬ 
sive  use  of  all  these  features  in  the  implementation) . 
Finally,  routines  with  critical  performance  requirements 
that  cannot  be  met  with  PL/M-86  may  be  written  in  ASM-86, 
the  8086  assembly  language,  and  then  linked  with  the  PL/M-86 
code.  For  example,  the  Virtual  Processor  Scheduler  of  the 
Inner  Traffic  Controller  level  is  written  in  ASM-86, 
b.  Processor  Architecture 

Microprocessors  generally  execute  a  program  by 
repeatedly  cycling  through  the  steps  shown  below: 

(1)  Fetch  the  next  instruction  from  memory. 

(2)  Read  an  operand  (if  required  by  the  instruc¬ 
tion)  . 

(3)  Execute  the  instruction. 

(4)  Write  the  result  (if  required  by  the  instruc' 

tion) . 

The  architecture  of  8086,  while  performing  the 
same  steps,  allocates  them  to  two  separate  processing  units 
within  the  CPU  (see  Figure  11).  The  execution  unit  (EU) , 
executes  instructions.  The  bus  interface  unit  (BIU)  fetches 
instructions,  reads  operands  and  writes  results.  These  two 
units  can  operate  independently  of  one  another  and  are  able, 
under  most  circumstances,  to  extensively  overlap  instruction 
fetches  with  execution. 
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11.  EXECUTION  AND  BUS  INTERFACE  UNITS  (EU  AND  BIU) 


The  result  is  that,  in  most  cases,  the  time 


normally  required  to  fetch  instructions  "disappears", 
because  the  EU  executes  instructions  that  have  already  been 
fetched  by  the  BIU. 

A  16-bit  arithmetic/logic  unit  (ALU)  in  the  EU 
maintains  the  CPU  status  and  control  flags  and  manipulates 
the  general  registers  and  instruction  operands.  All  registers 
and  data  paths  in  the  EU  are  16-bits  wide  for  fast  internal 
transfers.  The  EU  has  no  connection  to  the  system  bus,  the 
"outside  world".  It  obtains  instructions  from  a  queue 
maintained  by  the  BIU.  Likewise  when  an  instruction  requires 
access  to  memory  or  to  a  peripheral  device,  the  EU  requests 
the  BIU  to  obtain  or  store  the  data.  All  addresses  manipulated 
by  the  EU  are  16-bits  wide. 

The  BIU  performs  an  address  relocation  that 
gives  the  EU  access  to  the  full  Megabyte  of  memory  space. 

BIU  performs  all  bus  operations  for  the  EU.  Data  is  trans¬ 
ferred  between  the  CPU  and  memory  or  I/O  devices  upon  demand 
from  the  EU.  In  addition,  during  periods  when  the  EU  is  busy 
executing  instructions,  the  BIU  "looks  ahead"  and  fetches 
more  instruction  from  memory.  The  instructions  are  stored 
in  an  internal  RAM  array  called  the  instruction  stream  queue 
(which  can  store  up  to  six  instruction  bytes) .  This  queue 
size  allows  the  BIU  to  keep  the  EU  supplied  with  prefetched 
instructions,  under  most  conditions  without  monopolizing  the 
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system  bus.  The  BIU  fetches  another  instruction  byte,  when¬ 
ever  there  are  two  empty  bytes  in  its  queue  and  there  is  no 
active  request  for  bus  access  from  the  EU  (BIU  normally 
obtains  two  instructions  bytes  per  fetch) . 

Under  most  circumstances  the  queue  contains  at 
least  one  byte  of  the  instruction  stream,  and  so  the  EU  does 
not  have  to  wait  for  instructions  to  be  fetched.  The  instruc¬ 
tions  in  the  queue  are  the  next  logical  instructions  as 
long  as,  execution  proceeds  serially.  If  the  EU  executes  an 
instruction  that  transfers  control  to  another  location,  then 
the  BIU  resets  the  queue  and  fetches  the  instruction  from 
the  new  address,  passes  it  immediately  to  the  EU,  and  then 
begins  refilling  the  queue  from  the  new  location.  In  addition, 
the  BIU  suspends  instruction  fetching  whenever  the  EU  requests 
a  memory  or  I/O  read  or  write  (except  that  a  fetch  already  in 
progress  is  completed  before  executing  the  EU's  bus  request), 
c.  CPU  Registers 

There  are  eight  16-bit  general  registers.  The 
general  registers  are  subdivided  into  two  sets  of  four 
registers  each.  The  first  set,  called  the  "H  and  L”  group 
(for  "high"  and  ''low"),  are  the  data  registers.  The  second 
set,  called  the  "P  and  I"  group,  are  the  pointer  and  index 
registers  (see  Figure  12). 

The  data  registers  have  their  upper  (high)  and 
lower  (low)  halves  separately  addressable.  This  means  that 
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each  data  register  can  be  used  interchangeably  as  a  16-bit 
register  or  as  two  8-bit  registers.  The  other  CPU  registers 
always  are  accessed  as  16-bit  units  only.  The  data  registers 
can  be  used  without  constraint  in  most  arithmetic  and  logic 
operations.  In  addition,  some  instructions  use  certain 
registers  implicitly  (see  Figure  13) ,  thus  allowing  compact 
yet  powerful  encoding. 

The  pointer  and  index  registers  can  also  par¬ 
ticipate  in  most  arithmetic  and  logic  operations.  The  P  and  I 
registers  (except  for  BP)  also  are  used  implicitly  in  some 
instructions,  as  shown  in  Figure  13. 

The  16-bit  instruction  pointer  (IP)  (analogous 
to  the  program  counter,  PC,  in  the  8080  CPU)  is  updated  by 
the  BIU,  so  that  it  contains  the  offset  (distance  in  bytes) 
of  the  next  instruction  from  the  beginning  of  the  current  code 
segment.  IP  points  to  the  next  instruction.  During  normal 
execution  IP  contains  the  offset  of  the  next  instruction 
to  be  "fetched  by  the  BIU".  Whenever  IP  is  saved  on  the  stack, 
it  first  is  automatically  adjusted  to  point  to  the  next 
instruction  to  be  "executed".  Programs  do  not  have  direct 
access  to  the  IP,  but  instructions  cause  it  to  change  and  to 
be  saved  on  and  restored  from  the  stack. 

The  8086  has  six  1-bit  "status  flags"  that  the 
EU  posts  to  reflect  certain  properties  of  the  result  of  an 
arithmetic  or  logic  operation.  A  group  of  instructions  is 
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IN  GENERAL  THE  FLAGS  REFLECT  THE  FOLLOWING  CONDITIONS: 

(1)  AF:  Auxiliary  Carry  Flag  (6)  ZF:  Zero  Flag 

(2)  CF:  Carry  Flag  (7)  DF:  Direction  Flag 

(3)  OF:  Overflow  Flag  (8)  IF:  Interrupt  Flag 

(4)  SF:  Sign  Flag  (9)  TF:  Trap  Flag 

(5)  PF:  Parity  Flag 

FIGURE  14.  FLAGS  71 


available  that  allows  a  program  to  alter  its  execution 
depending  on  the  state  of  these  flags,  that  is,  on  the  result 
of  a  prior  operation.  Three  additional  "control  flags"  can 
be  set  and  cleared  by  programs  to  alter  processor  operations 
(see  Figure  14). 

d.  Segmentation  -  Segment  Registers 

The  8086  does  not  support  the  notion  of  explicit 
segmentation.  In  the  8086,  addressing  is  segmentlike,  in 
that  the  base  and  offset  (two-dimensional)  addressing  is  used. 
8086  programs  "view"  the  one  Megabyte  of  memory  space  as  a 
group  of  segments  that  are  defined  by  the  application.  A 
segment  is  a  logical  unit  of  memory  that  may  be  up  to  64K 
bytes  long.  Each  segment  is  made  up  of  contiguous  memory 
locations  and  is  an  independent  separately-addressable  unit. 

Every  segment  is  assigned  (by  software)  a  base 
address  which  is  its  starting  location  in  the  memory  space. 

All  segments  begin  on  16-byte  memory  boundaries.  There  are 
no  other  restrictions  on  segment  locations.  Segment  may  be 
adjacent,  disjoint,  partially  overlapped  or  fully  overlapped 
(see  Figure  15).  However,  in  this  operating  system  design  a 
physical  memory  location  cannot  be  mapped  on  (contained  in) 
more  than  one  logical  segment. 

The  segment  registers  point  to  (contain  the  base 
address  values  of)  the  four  currently  addressable  segments 
(See  Figure  17) .  Programs  obtain  access  to  code  and  data  in 
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other  segments  by  changing  the  segment  register,  to  point  to 
the  desired  segment. 

Every  application  can  define  and  use  segments 
differently.  The  currently  addressable  segments  provide  a 
generous  work  space  of  64K  bytes  for  code,  64K  bytes  for 
stack,  and  128K  bytes  of  data  storage. 

The  CPU  has  direct  access  to  four  segments  at  a 
time.  Their  base  addresses  (starting  locations)  are  contained 
in  the  segment  registers  (see  Figure  16) . 

In  this  implementation  these  four  base  segment 
registers  of  the  8086  microprocessor  are  utilized  as  follows: 

(1)  Code  Segment  Register  (CS  register)  is  used 
for  addressing  a  pure  segment  containing  executable  code. 

CS  register  points  to  the  current  code  segment.  Instructions 
are  fetched  from  this  segment. 

(2)  Data  Segment  Register  (DS  register)  is  used 
for  processing  local  data.  The  DS  register  points  to  the 
current  data  segment  that  generally  contains  program  variables. 

(3)  Stack  Segment  Register  (SS  register)  is  used 
for  implementing  the  per  process  stacks  (kernel  stack  and  user 
stack) .  SS  register  points  to  the  current  stack  segment. 

Stack  operations  are  performed  on  locations  in  this  segment. 

(4)  Extra  Segment  Register  (ES  register)  is 
typically  used  for  external  or  shared  data.  ES  register 
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FIGURE  17.  CURRENTLY  ADDRESSABLE  SEGMENTS 


points  to  the  current  extra  segment  (which  also  is  typically 
used  for  data  storage) . 

In  the  8086,  a  segment  can  range  anywhere  up  to 
64  kilo-bytes  in  length.  Segments  can  be  placed  anywhere 
within  the  1  mega-byte  address  space  of  the  8086  as  long  as 
the  segment  hexadecimal  base  is  placed  so  that  the  last  digit 
of  the  base  is  zero.  Segment  access  and  bounds  checking 
are  not  supported.  Although  there  is  no  general  segmentation 
hardware,  this  design  effects  a  segmented  address  space 
through  a  combination  of  operating  system  support  and  system 
initialization  conventions  described  in  a  thesis  by 
Anderson  [19]. 

e.  Physical  Address  Generation 

It  is  useful  to  think  of  every  memory  location 
having  two  kinds  of  addresses,  "physical"  and  "logical".  A 
physical  address  is  the  20-bit  value  that  uniquely  ident¬ 
ifies  each  byte  location  in  the  Megabyte  memory  space. 
Physical  addresses  may  range  from  OH  through  FFFFFH.  All 
exchanges  between  the  CPU  and  memory  components  use  this 
physical  address. 

Programs  deal  with  the  logical  rather  than 
physical  addresses  and  allow  code  to  be  developed  without 
prior  knowledge  of  where  the  code  is  to  be  located  in  memory 
this  facilitates  dynamic  management  of  memory  resources. 
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FIGURE  18.  LOGICAL  AND  PHYSICAL  ADDRESSES 


A  logical  address  consists  of  a  segment  base 
value  and  an  offset  value.  For  any  given  memory  location 
the  segment  base  value  locates  the  first  byte  of  the  con¬ 
taining  segment  and  the  offset  value  is  the  distance  in 
bytes  of  the  target  location  from  the  beginning  of  the 
segment. 

Segment  base  and  offset  values  are  unsigned 
16-bit  quantities.  The  lowest-addressed  byte  in  a  segment 
has  an  offset  of  0. 

Whenever  the  BIU  accesses  memory  to  fetch  an 
instruction  or  to  obtain  or  store  a  variable,  it  generates 
a  physical  address  from  the  corresponding  logical  one.  This 
is  done  (see  Figure  19)  by  shifting  the  segment  base  value 
four  bit  positions  to  the  left  and  adding  the  offset. 

f.  The  iSBC  86/12A  Single  Board  Microcomputer 

The  86/12A  is  a  complete  computer  capable  of 
"stand-alone  operation”  used  as  the  basic  processing  node  of 
the  multiprocessor.  The  iSBC  86/12A  Board  includes  a  16-bit 
central  processing  unit  (CPU) ,  32K  bytes  of  dynamic  RAM,  a 
serial  communications  interface,  three  programmable  parallel 
I/O  ports,  programmable  timers,  priority  interrupt  control. 
Multibus  interface  control  logic,  and  bus  expansion  drivers  for 
interface  with  other  Multibus  interface  compatible  expansion 
boards.  Provision  has  been  made  for  user  installation  of  up 
to  16k  bytes  of  read  only  memory  (ROM) .  iSBC  86/12A  is  a 
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commercial  product  which  satisfies  the  three  basic  hardware 
requirements  for  this  operating  system  mentioned  in  above 
subparagraph  A  (HARDWARE  REQUIREMENTS) .  First,  it  must 
possess  a  system  bus  interface.  Each  microcomputer  is  capable 
of  independently  accessing  a  global  shared  memory  via  the 
system  bus.  Secondly,  the  8086  CPU  supports  multiprocessor 
synchronization  directly  with  an  indivisible  " test-and-set 
semaphore"  instruction,  which  performs  the  bus  lock.  Lock 
semaphores  reside  in  the  shared  global  memory.  Thirdly, 
preempt  interrupts  can  be  generated  by  using  a  bit  of  a 
parallel  I/O  port  provided  on  each  microcomputer.  This 
requires  connecting  a  bit  of  the  microcomputer's  parallel 
I/O  port  to  the  system  interrupt  structure. 

g.  Preempt  Interrupt  Hardware  Connection 

As  with  most  microprocessors,  the  8086  itself 
does  not  possess  the  capability  to  directly  generate  interrupts 
destined  for  other  devices.  The  devices  of  interest  here  are 
the  other  processors.  We  need  this  capability  for  the 
implementation  of  preemptive  scheduling.  The  system  interrupt 
lines  are  accessible  through  a  jumper  matrix  [2]  located  on 
the  microcomputers.  The  parallel  I/O  output  port  of  each 
iSBC  86/12A  is  connected  to  this  interrupt  jumper  matrix. 
Preempt  interrupts  are  then  generated  by  the  system  simply 
by  outputting  a  single  word,  through  the  parallel  port,  onto 
the  system  interrupt  lines. 
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Note  that  only  a  single  interrupt  line  is 
actually  required  to  implement  system-wide  preempt  interrupts. 
For  details  see  the  next  chapter. 

h.  On  Board  Bus  Structure  -  System  Bus 

The  iSBC  86/12A  board  architecture  is  organized 
around  a  three-bus  hierarchy:  the  on-board  bus,  the  dual 
port  bus,  and  the  Multibus  interface  (see  Figure  20) .  Each 
bus  can  communicate  only  within  itself  and  an  adjacent  bus 
and  also  each  bus  can  operate  independently  of  each  other. 

The  on-board  bus  connects  the  CPU  to  all  on-board  I/O 
devices,  ROM/EPROM,  and  the  dual  port  RAM  bus.  Activity  on 
this  bus  does  not  require  control  of  the  outer  buses,  thus 
permitting  independent  execution  of  on-board  activities. 
Activities  at  this  level  require  no  bus  overhead  and  operate 
at  maximum  board  performance. 

The  next  bus  in  the  hierarchy  is  the  dual  port 
bus.  This  bus  controls  the  dynamic  RAM  and  communicates  with 
the  on-board  bus  and  the  Multibus  interface. 

When  the  on-board  bus  needs  the  Multibus  inter- 
face,  it  must  go  through  the  dual  port  bus  to  the^, Multibus 
interface.  The  iSBC  86/12A  Board  is  completely  Multibus 
interface  compatible  and  supports  both  8-bit  and  16-bit 
operations. 

The  Intel  MULTIBUS  [2]  is  utilized  as  the  system 
bus.  It  is  a  widely  used  commercial  product  with  a  published 
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FIGURE  20.  INTERNAL  BUS  STRUCTURE 


set  of  standards.  This  bus  is  specifically  designed  to 
support  multiple  processors  and  is  fully  compatible  with  the 
microcomputers  used.  It  is  utilized  without  modifications. 

C.  HARDWARE  ASSESSMENT 

The  commercially  available  86/12A  single  board  micro¬ 
computer  was  chosen  because  it  was  specifically  designed 
to  provide  support  for  multiple  processor  systems.  In  using 
the  operating  system  described  in  the  next  chapter  to  manage 
the  microcomputer's  physical  resources,  this  microcomputer 
is  entirely  suitable  for  use  as  a  basic  processing  node  of 
an  effective  multiprocessor  system.  For  multiprocessor 
interconnections  see  Figure  21. 
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IV.  DETAILED  SYSTEM  DESIGN  AND  IMPLEMENTATION 

A.  STRUCTURE  OF  THE  OPERATING  SYSTEM 

The  distributed  modules  of  the  kernel  create  a  virtual 
machine  hierarchy  which  controls  process  interactions  and 
manages  physical  processor  resources.  The  kernel  is  not 
aware  of  the  details  of  process  tasks.  It  knows  each 
process  only  by  a  name  (as  an  entry  in  the  Active  Process 
Table)  and  provides  processes  with  scheduling  and  inter¬ 
process  communication  and  synchronization  services  based  on 
this  process  identity. 

The  kernel  is  constructed  in  terms  of  layers  of 
abstraction.  Each  layer,  or  level,  builds  upon  the  resources 
created  at  lower  levels.  The  rules  of  abstraction  described 
in  Chapter  II  were  applied  to  the  design  of  this  structure. 

This  operating  system  provides  a  multiprogrammed  multi¬ 
processor  system  with  segmented  process  address  spaces  using 
the  hardware  described  in  Chapter  III.  The  operating  system 
is  structured  as  a  hierarchy  of  four  levels  of  abstraction, 
as  follows: 

Level  3:  Supervisor 

Level  2:  Traffic  Controller 

Level  1:  Inner  Traffic  Controller 

Level  0:  Hardware  (Bare  machine) ,  (See  Figure  5) . 

Level  0  is  the  bare  machine  which  provides  the  physical 
resources  (processors  and  storage)  upon  which  the  virtual 
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machine  is  constructed  to  give  the  extended  machine 
view. 

The  remainder  of  this  chapter  will  describe  the  level  of 
virtualization  (or  layer  of  abstraction)  created  by  each 
distributed  kernel  module. 

The  Inner  Traffic  Controller  (Level  1)  forms  the  first 
level  of  the  hierarchy.  It  is  "closest"  to  the  hardware  and 
encompasses  the  major  machine-dependent  aspects  of  the  system. 
The  Inner  Traffic  Controller  multiplexes  the  physical 
processors  among  a  pool  of  more  numerous  virtual  processors. 

Residing  at  the  next  level  (Level  2)  is  the  Traffic 
Controller,  which  is  responsible  for  multiplexing  the  virtual 
processors  among  a  larger  number  of  user  processes  competing 
for  resources.  The  user-accessible  inter-process  communication 
and  synchronization  primitives  (Advance,  Await  and  Ticket) 
provided  at  this  level  allow  the  user  to  easily  satisfy  complex 
system-wide  inter-process  synchronization  requirements. 

The  Supervisor  resides  at  the  topmost  level  (Level  3) . 

The  Supervisor's  purpose  is  to  provide  common  services  for 
user  processes.  In  this  implementation  it  only  provides  a 
simple  assembly  language  interface  to  the  kernel  by  having 
a  single  entry  point  into  the  kernel  (the  Gate  or  Gatekeeper) . 

B.  CONTROL  OF  PROCESSOR  MULTIPLEXING 

There  are  two  common  schemes  for  the  control  of  processor 
multiplexing:  "centralized  control"  and  "distributed  control". 
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Centralized  control  is  based  on  the  idea  of  a  central 
agent  which  is  responsible  for  the  binding  of  virtual  pro¬ 
cessors  to  real  processors.  All  these  bindings  are  caused  by 
the  action  of  the  central  agent.  This  agent  can  be  viewed 
as  a  process,  since  it  is  a  sequential  computation  that  per¬ 
forms  operations  on  the  state  of  the  system.  In  this  scheme 
of  control  usually  this  central  agent  is  permanently  bound 
to  a  dedicated  real  processor.  Of  course  this  implementation 
requires  some  kind  of  communication  channel  between  the  real 
processors  and  the  central  agent. 

The  main  advantage  of  the  centralized  algorithm  is,  "unity" 
Since  the  centralized  scheme  is  executed  as  a  process  permanent 
ly  bound  to  one  real  processor,  it  can  be  described  by  a  single 
sequential  program  that  makes  one  decision  at  a  time  (that 
means  a  simply  structured  processor  multiplexing  policy) . 

An  alternative  scheme  for  the  control  of  processor  multi¬ 
plexing  is  one  in  which  the  functions  are  accomplished  by  a 
distributed  algorithm,  executed  by  each  process  on  all  real 
processors. 

The  main  advantage  of  the  distributed  scheme  is,  "autonomy" 
This  autonomy  afforded  by  a  distributed  system  can  increase 
the  amount  of  parallel  activity  (real  processors  can  execute 
in  parallel) .  This  scheme  also  results  in  a  uniform  design 
that  is  identical  for  every  processor. 

The  advantages  of  each  scheme  are  disadvantages  of  the 
other.  In  the  centralized  case  the  lack  of  autonomy  prohibits 
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the  parallelism  afforded  by  the  distributed  scheme.  On  the 
other  hand,  in  the  distributed  case,  the  autonomy  makes  it 
potentially  difficult  to  understand  the  interaction  of  the 
multiplexing  algorithm  executed  by  different  real  processors. 

1 .  Distributing  the  Operating  System 

One  of  the  primary  concerns  in  any  multiple  computer 
system  is  the  issue  of  performance.  The  type  of  system  in 
the  present  implementation  is  a  multiprocessor  with  a  "single" 
shared  system  bus.  Thus  the  most  glaring  potential  "bottle¬ 
neck"  is  the  system  bus.  Thus  it  becomes  desirable  to 
minimize  accesses  to  this  resource  which  must  be  shared  by 
all  of  the  real  processors. 

The  decision  was  made  to  "distribute"  the  operating 
system  logically  and  physically  to  reduce  the  "system  bus" 
use.  Logically  the  segments  of  the  operating  system  kernel 
are  distributed  within  (as  part)  the  address  space  of  each 
user  process.  On  the  other  hand,  the  performance  issue  is 
dealt  with  by  physically  distributing  copies  of  the  kernel  in 
the  local  memories  of  each  of  the  real  processors.  This  allows 
high-speed  access  to  kernel  functions  without  necessitating 
the  heavy  use  of  the  system  bus  for  code  fetches  thus 
reducing  "BUS  contention". 

Since  the  operating  system  is  small,  the  memory  wasted 
by  distributing  a  copy  of  the  kernel  to  each  single  board 
computer  is  a  small  price  to  be  paid  to  allow  performance  to 
grow  with  the  addition  of  real  processors. 
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Thus,  each  computing  node  can  be  regarded  as  "semi- 
autonomous"  in  that  each  of  the  processors  schedules  itself. 
The  modes  are  still  centrally  controlled  by  the  set  of  system- 
wide  data  tables,  kept  in  the  global  memory,  which  provides 
access  to  all  real  processors  and  thus  eliminates  the  need  of 
a  central  controlling  process.  The  amount  of  memory  needed 
for  these  system-wide  data  tables  is  almost  negligible. 

In  this  implementation  there  is  no  notion  of  a  master- 
slave  relationship  among  individual  microcomputers,  nor  are 
individual  kernel  functions  divided  among  them,  as  is 
commonly  done.  Rather,  the  "entire"  kernel  is  distributed  on 
each  single  board  computer. 

C.  REAL  TIME  PROCESSING 

Real-time  control  systems  are  designed  for  handling  data 
within  a  time  period  which  is  consistent  with  the  response 
time  demanded  by  the  process  which  generated  the  information. 
Such  systems  operate  in  a  multi-programmed  environment  where 
the  execution  of  a  number  of  tasks  is  determined  by  the  soft¬ 
ware  priorities,  hardware  interrupts,  timing  algorithms  and 
requests  from  other  tasks  (requests  from  one  task  to  start, 
suspend  or  terminate  another  task)  to  pass  data  from  one  task 
to  another. 

A  real-time  operating  system  must  be  designed  so  that  it 
is  impossible  for  any  program  and  any  user  to  interfere  with 
the  execution  of  critical  tasks  by  halting  the  machine,  by 
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changing  interrupt  priorities  or  by  innappropriately  overwriting 
memory. 

Real-time  processing  involves  the  performance  of  time- 
critical  processing  often  related  to  the  control  of  external 
devices.  This  application  requires  that  some  mechanism  be 
employed  to  ensure  that  the  time-critical  processing  is 
given  immediate  attention. 

The  hardware-supported  "process  preemption"  mechanism 
employed  in  the  system  provides  the  rapid  response  required 
for  real-time  processing.  The  priority-driven  preemptive 
scheduling  technique  used  provides  for  expeditious  handling 
of  processes  which  perform  the  time-critical  functions.  These 
processes  are  assigned  high  priorities  so  that  the  system  will 
preempt  other  processes  of  lower  priority  which  may  be  in  the 
running  state.  Thus  when  one  of  these  high-priority  processes 
is  signalled,  it  can  be  immediately  scheduled  and  thus  gain 
control  of  the  processor  resources. 

The  actual  system  response  time  for  a  task  request  depends 
mainly  on  whether  or  not  another  task  is  running  at  a  higher- 
priority  level.  To  prevent  high-priority  tasks  from  executing 
too  long,  a  "watchdog  timer"  is  often  used  to  guarantee  that 
all  tasks  are  serviced.  This  timer  is  set  at  the  start  of  each 
task  with  the  maximum  duration  that  a  task  may  run  at  a 
particular  priority  level  before  being  suspended  or  dropped. 

This  watchdog  timer  is  not  yet  implemented  but  it  will  be  a 
useful  added  capability. 
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D.  SCHEDULING 


Processor  multiplexing  and  process  multiplexing  require 
a  policy,  called  the  Processor/Process  multiplexing  policy 
algorithm,  or  simply  "Scheduling"  algorithm. 

In  this  design  the  scheduling  functions  are  divided 
between  the  Inner  Traffic  Controller  and  the  Traffic  Control¬ 
ler  levels.  The  Inner  Traffic  Controller  multiplexes  Virtual 
Processors  among  Real  Processors.  Each  Real  Processor 
possesses  a  fixed  number  of  Virtual  Processors  (4  in  the 
current  version) .  At  any  one  time  the  Real  Processor  can 
only  execute  "one"  Virtual  Processor.  The  choice  of  the 
Virtual  Processor  that  will  run  in  each  Real  Processor  is 
decided  by  the  Virtual  Processor  Scheduler  (VPSCHEDULER) 
that  is  a  routine  in  the  Inner  Traffic  Controller  level. 

The  Traffic  Controller  multiplexes  Processes  among  Virtual 
Processors.  The  Traffic  Controller  Scheduler  (TC$SCHEDULER) 
is  responsible  for  that  scheduling.  Both  scheduling  algorithms 
are  "priority  driven" •  (The  highest  priority  Virtual  Processor 
or  Process  will  run  first) .  These  algorithms  receive  as  input 
the  set  of  Virtual  Processors  and  Processes  respectively,  that 
can  be  run  and  choose  the  next  one  to  run. 

More  details  will  be  presented  when  we  will  discuss  the 
algorithm  of  these  two  "scheduler"  modules. 

E.  PROCESS  ADDRESS  SPACE 

The  address  space  of  a  process  is  a  set  of  PL/M-86  segments 
such  as  procedures  (code) ,  local  variables  (data) ,  external 
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data  (shared  data)  and  a  stack.  Physical  memory  is  allocated 
to  the  segments  of  a  process  in  such  a  way  as  to  limit  system 
bus  contention,  as  discussed  by  Anderson  [19] .  In  this 
implementation  the  concept  of  a  "per  process  stack"  is  a 
key  element  in  the  management  of  processes. 

1.  The  PL/M-86  Stack 

Intel's  high  level  language  PL/M-86  [1,6]  utilizes  the 
stack  segments  to  implement  per  process  stacks.  Addressing 
of  stacks  is  accomplished  by  using  three  of  the  8086 's 
registers  as  shown  in  Figure  22.  The  Stack  Segment  (SS) 
Register  contains  the  base  location  of  the  stack  segment  in 
memory.  The  Stack  Pointer  (SP)  Register  addresses  the  current 
top  of  the  stack  as  an  offset  from  the  base  of  the  stack 
segment,  (the  value  in  the  SS  Register) .  The  Base  Pointer 
(BP)  Register  also  holds  an  offset  from  the  SS  Register  and 
is  used  to  establish  the  procedure  activation  records  [3,  4, 

5] .  During  the  "process  creation"  in  the  current  version  of 
the  operating  system  one  of  the  parameters  passed  to  the 
operating  system  for  a  specific  process  is  the  initial  value 
of  the  SP  register  ("maximum  stack  length") .  It  is  used  to 
assure  no  "stack  overflow".  If  the  process  has  only  one 
module,  the  "maximum  stack  length"  can  be  extracted  for  the 
specific  process  during  its  preparation  (Compilation-Linking- 
Locating)  .  Specifically  the  LST  output  file  of  the  Compiler 
(file  name. LST)  at  the  end  provides  the  information  illus¬ 
trated  in  Figure  23. 
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FIGURE  22.  PL/M  STACK  STRUCTURE 


There  is  also  a  second  way  to  extract  this  information 
using  the  MP2  output  file  of  the  Locater  (file  name.MP2) . 
This  method  can  be  used  also  when  a  process  consists  of 


several  modules  linked  together.  At  the  end  of  MP2  file  is 
found  the  maximum  stack  size  as  shown  in  Figure  24. 
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FIGURE  24.  MAXIMUM  STACK  SIZE  (  B AMPLE  MP2  LOCATER  OUTPUT) 


To  obtain  the  above  "maximum  stack  size"  infoxrmation  the 
command  "COPY  :F1:  File  name.LST  TO  :CO:"  is  typed  on  the  MDS 


(INTEL'S  Microcomputer  Development  System)  after  the  compila¬ 
tion  or  the  command  "COPY  :F1:  File  name.MP2  TO  :C0:"  after 


• 

the  Locating  Process.  These  commands  will  present  the 
Compiler  or  Locater  output  file  on  the  CRT  screen  of  the  MDS. 
If  one  prefers  to  have  this  output  on  the  printer,  just 
change  " : CO : "  to  " : TO : " . 

In  the  same  way  we  can  extract  the  information  on  the 
maximum  stack  size  of  the  kernel. 

In  the  current  version  of  the  operating  system,  we  use 
two  "per  process"  stacks  dividing  the  "address  space"  of  each 
process  into  two  "domains"  of  execution  and  separating  che 
"user  domain"  from  the  "kernel  domain" .  We  call  the 
corresponding  stacks  the  "user  stack"  and  the  "kernel  stack". 

In  this  version: 

Maximum  Kernel  Stack  Length  = 

Maximum  Stack  Size  for  the  Kernel  +10  and 

Maximum  User  Stack  Length  = 

Maximum  Stack  Size  for  the  "User  Program" "Linked"  with 
the  "Gate"  +  10. 

This  value  10  is  used  to  avoid  overwriting  the  "stack 
header"  shown  on  Figure  26  which  occupies  the  first  words 
in  the  stack,  just  above  the  stack  base.  It  is  important  to 
make  a  distinction  between  the  "User  Program"  or  "Application 
Program"  and  the  "User  Process"  or  Application  Process".  The 
User  or  Application  program  is  the  "job"  submitted  to  the 
operating  system  and  the  User  or  Application  Process  is  this 

< 
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program  in  execution  on  a  processor  and  is  the  submitted  job 
linked  with  the  distributed  part  of  the  Operating  system.  In 
Figure  25,  we  can  see  the  User  Program  as  the  "subset  A"  and 
the  distributed  part  of  the  operating  system  as  the  "subset  B" . 

The  running  User  Process  (this  program  in  execution)  is 
the  "Union  C"  of  these  subsets  A  and  B,  (C  =  AUB) .  This 
connection  (linking)  of  the  job  with  the  operating  system  is 
accomplished  via  the  "Gate." 

2 .  The  Stack  as  the  "Address  Space  Descriptor" 

In  this  system  the  per  process  stacks  are  used  to 
maintain  the  process  state  information.  This  includes  the 
current  execution  point  (when  the  process  is  not  actually 
running)  and  the  locations  of  the  code  and  data  segments. 

This  allows  the  system  to  "swap"  in  a  new  address  space 
(viz.,  do  a  "context  switch")  by  changing  "only"  the  value 
in  the  SS  Register  which  is  thus  used  in  a  manner  somewhat 
analogous  to  the  MULTICS  "Descriptor  Base  Register"  (DBR)  [9] . 
Then  the  operating  system  finds  the  remaining  of  the  needed 
information  to  run  the  specific  Process  inside  its  stack. 

Figure  26  shows  how  this  information  is  stored  in  the 
kernel  stack  while  a  process  is  not  actually  running  on  a 
physical  processor.  The  Base  Pointer  and  Stack  Pointer  are 
stored  in  reserved  locations  at  the  very  beginning  of  the 
stack  segment,  ("header"  of  the  Stack) .  Figure  26  illustrates 
the  status  of  the  kernel  stack  after  an  interrupt  within  the 
kernel . 
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THE  KERNEL  STACK  AS  THE  "ADDRESS  SPACE  DESCRIPTOR" 
(AFTER  RESPONDING  TO  AN  INTERRUPT) 
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In  order  to  identify  the  stack  segment  and  thus 
access  the  address  space  of  a  process,  the  stack  segment  base 
address  is  used  in  a  dual  role.  First,  a  "unique  base  address 


is  assigned  to  the  stack  of  each  process  which  provides  a 
"unique  segment"  for  each  stack.  This  base  address  is  used 
for  addressing  locations  within  the  stack.  Secondly,  the 
base  address  serves  as  a  descriptor  for  the  address  space  of 
each  process.  Thus  the  binding  of  a  processor  is  changed  from 
one  process  to  another  "merely"  by  changing  the  base  address, 
viz.,  changing  the  value  in  the  Stack  Segment  (SS)  Register. 
Figure  26  illustrates  how  the  "per  process"  Kernel  Stack  is 
implemented  in  the  current  version  of  the  Operating  System. 

More  details  about  the  currently  used  Stack  mechanism  (two 
per  process  stacks,  two  domains  of  execution)  will  be  discussed 
when  we  describe  the  "Create  Process"  module  of  the  Traffic 
Controller. 

F.  COMMUNICATION  AND  SYNCHRONIZATION 
1 .  Process  Synchronization 

The  problem  of  process  synchronization  arises  from  the 
need  to  share  resources  in  a  computer  system.  This  sharing 
requires  coordination  and  cooperation  to  ensure  correct  oper¬ 
ation.  This  coordination  is  forced  upon  the  processes  by  the 
operating  system  because  of  the  scarcity  of  resources,  for 
example,  the  need  to  wait  for  access  to  an  I/O  channel,  in 
other  cases  a  simple  job  may  consist  of  several  interactive 
processes,  such  as  an  airline  reservation  system. 
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Associated  with  processor  allocation  and  interprocess 
synchronization  are  two  synchronization  problems,  "race 
condition"  and  "deadly  embrace"  or  "deadlock  situations". 

2 .  "Race  Condition" 

A  race  condition  occurs  when  a  desired  action  cannot 
be  completed  in  one  indivisible  step.  For  example,  in  order 
to  gain  exclusive  control  of  a  printer  in  Process  1  in 
Figure  27,  it  is  important  to  check  if  the  printer  is  already 
in  execlusive  use  by  Process  2.  If  a  flag  is  used  (F=0,  not 
in  use)  (F=l,  in  use)  to  indicate  whether  or  not  the  printer 


FIGURE  27.  A  SIMPLE  RACE  CONDITION 
is  in  execlusive  use,  then  this  flag  has  to  be  interrogated. 

If  Process  1  interrogates  F  and  finds  its  value  is  zero, 
then  it  can  set  the  value  of  F  to  one  and  enjoy  the  execlusive 
use  of  the  printer.  A  problem  arises  when  both  Process  1 
and  Process  2  nearly  simultaneously  interrogate  the  flag  in 
the  following  sequence: 
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In  this  case  both  processes  falsely  gain  the  impression  that 
they  have  exclusive  use  of  the  printer.  This  so  called 
"race  condition"  can  be  avoided  by  an  indivisible  test  and 
set  operation  which  would  prevent  Process  2  being  mislead. 

Such  a  test  and  lock  operation  is  the  8086  LOCKSET  built-in 
procedure . 

In  addition  to  physical  devices,  there  are  other 
shared  resources,  such  as  a  shared  database,  that  require 
the  same  type  of  synchronization  to  avoid  race  conditions. 

For  example,  in  this  implementation  in  order  to  avoid  race 
conditions  in  the  shared  databases  APT  and  VPM,  we  implemented 
a  lock  per  database.  When  a  Virtual  Processor  needs  to  read 
or  update  the  shared  database,  it  locks  this  common  table 
(this  way  it  locks  out  all  the  other  Virtual  Processors) . 

After  the  completion  of  this  action  the  Virtual  Processor 
unlocks  the  database,  so  another  Virtual  Processor  can 
access  it. 

3 .  "Deadly  Embrace"  or  "Deadlock  Situations" 

A  "deadly  embrace"  is  a  situation  in  which  two  pro¬ 
cesses  are  unknowingly  waiting  for  resources  that  are  held 
by  each  other  and  thus  unavailable  [15].  See  Figure  28. 
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FIGURE  28.  DEADLY  EMBRACE  SITUATION 

"A"  and  "B"  are  sharing  the  use  of  the  printer  and  card 
reader  by  means  of  the  request  and  release  operations  (as 
stated  in  the  previous  paragraph) .  Due  to  independent 
scheduling  of  the  processes  the  ’'request"  and  "release"  oper¬ 
ations  may  be  interspersed  in  several  different  orders. 

Lets  consider  a  case  that  starts  with  A1  (request 
printer  for  process  "A")  and  B1  (request  reader  for  process 
"B").  If  then  A2  occurs  (request  reader  for  process  "A"), 
process  "A"  must  be  blocked  because  the  reader  is  already  in 
use  by  process  "B" .  Then  when  B2  occurs  (request  printer 
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for  process  " B"),  process  "B"  must  also  be  blocked  because 


the  printer  is  already  in  use  by  process  "A".  In  this  way 
we  confront  a  situation  where  each  process  is  waiting  for  the 
other  to  release  a  needed  resource.  A  deadly  embrace  situation 
is  resulted. 

We  have  already  concluded  that  synchronization  primi¬ 
tives  like  the  described  "request"  and  "release"  cannot  avoid 
"race  conditions"  and  "deadlock  situations".  Several  more 
sophisticated  synchronization  primitives  have  been  developed 
to  overcome  these  problems.  The  most  commonly  used  among 
them  are:  Dijkstra's  "P"  and  "V"  operations  on  "counting 
semaphores"  [12],  Saltzer's  "Block-Wakeup"  or  sometimes 
called  "Wait-Signal"  [14]  and  lastly  Kanodia  and  Reed's 
"Eventcounts"  and  "Sequencers"  [10] . 

4 .  Shared  Segment  Interactions.  Security 

In  the  paragraph  B5  of  Chapter  II  it  has  been  already 
discussed  that  the  implementation  of  this  operating  system 
has  not  considered  the  "internal  security"  of  the  system,  but 
in  the  design  there  are  all  the  ingredients  for  future  exten¬ 
sions  in  this  direction.  A  future  extension  also  is  the 
addition  of  "file  management".  We  shall  mention  here  two 
more  problems  which  are  related  to  the  selection  of  the 
synchronization  mechanism. 

a.  Confinement  Property 

During  the  last  five  years  the  security  kernel 
technology  has  demonstrated  not  only  that  a  kernel  can  provide 
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security  but  also  that  it  is  practical  in  terms  of  performance, 
functional  capability,  and  compatibility.  A  successful 
implementation  of  a  kernel  is  based  on  three  [23]  engineering 
principles:  (1)  "completeness",  in  that  all  accesses  to 

information  must  go  through  the  kernel;  (2)  "isolation",  in 
that  the  kernel  must  be  tamperproof;  and  (3)  "verifiability", 
in  that  there  must  be  a  direct  correspondence  to  the  model 
and  specification  requirements. 

A  secure  computer  system  will  not  occur  as  a 
spontaneous  result  of  other  design  goals.  Security  must  be 
explicitly  designed  in  from  first  principles,  and  this  is 
the  reason  why  the  confinement  problem  is  discussed  and  has 
influence  in  the  selection  of  the  synchronization  mechanism. 

The  major  problem  that  has  to  be  handled  for 
proper  system  security  is  the  "confinement  property"  or 
"*  property"  [24] . 

The  "confinement  property"  has  to  prevent  a  process 
from  "reading"  a  file  with  a  "higher  classification"  or 
"writing"  (i.e.,  storing  or  updating)  a  file  with  a  "lower 
classification" . 

b.  Readers/Writers  Problems 

Another  problem  closely  related  to  the  confinement 
problem  which  involves  the  Supervisor,  is  the  "readers/writers" 
problem  [25].  In  order  to  preserve  file  integrity,  reading 
and  writing  of  a  shared  file  cannot  be  allowed  at  the  same 
time. 


Both  the  confinement  and  readers/writers  problems 
can  be  solved  in  one  of  two  ways.  One  is  mutual  exclusion, 
a  mechanism  which  forces  a  time  ordering  on  the  execution  of 
critical  regions,  forces  concurrent  processes  into  a  total 
order  execution  sequence.  This  is  counterproductive  to  the 
purpose  of  the  process  structure  of  this  implementation, 
which  inherently  allows  concurrent  execution  of  processes. 

A  second  and  relatively  new  method  is  the  use  of 
Eventcounts  and  Sequencers  [10]  to  control  access  to  critical 
regions.  This  method  preserves  the  idea  of  concurrent 
processing  to  a  much  greater  extent  and  also  addresses  the 
confinement  property  for  a  security  kernel. 

5 .  Synchronization  Background 

In  order  to  keep  processor  multiplexing  simple,  it  is 
desirable  to  have  a  simple  interprocess  communication  and 
synchronization  mechanism.  Before  describing  the  "Eventcount¬ 
ing"  synchronization  mechanism  employed  in  the  design  and 
implementation  of  this  operating  system,  it  is  worthwhile  to 
discuss  two  generally  used  synchronization  mechanisms,  the 
"Semaphore"  and  "Block-Wakeup" . 
a.  The  "Semaphore" 

In  most  synchronization  schemes,  a  physical  entity 
must  be  used  to  represent  the  resource.  This  entity  is  often 
called  a  "lock  byte"  or  "semaphore".  Thus,  for  each  "shared 
database"  {for  example  APT  and  VPM  in  this  implementation) 
there  should  be  a  separate  lock  byte.  We  will  use  the 


convention  that  lock  byte  =  0  means  the  resource  is  available, 
whereas  lock  byte  =  1  means  the  resource  is  already  in  use. 

Before  operating  on  such  a  shared  resource,  a 
process  must  perform  the  following  actions  with  no  interrup¬ 
tion: 

1.  Examine  the  value  of  the  lock  byte  (either  it  is  0 

or  1)  . 

2 .  Set  the  lock  byte  to  1 . 

3.  If  the  original  value  was  1,  go  back  to  step  1. 

After  the  process  has  completed  its  use  of  the  resource,  it 
sets  the  lock  byte  to  zero.  Some  other  terms  used  for  this 
operation  are  "Test-And-Set"  instruction,  "Software  Lockout", 
"Indivisible  Read-Alter-Rewrite" ,  "Indivisible  Test-And-Set" 
semaphore,  "Spin-Lock”  procedure  and  so  on.  In  this  design 
we  use  a  built-in  PL/M-86  procedure  called  LOCKSET,  an 
indivisible  test-and-set  semaphore,  to  implement  software 
locks  in  shared  databases  (APT,  VPM) .  The  hardware  "bus  lock" 
is  used  to  make  the  operation  indivisible.  It  is  important 

to  note  that  the  lock  and  unlock  operations  do,  in  fact, 
prevent  "Race  Conditions". 

b.  "P"  and  "V"  Operations  On  Counting  Semaphores 
A  more  general  form  of  the  above  LOCK/UNLOCK 
mechanism,  called  the  "P"  and  "V"  operations,  has  been  defined 
by  Dijkstra  (1968) .  "P"  and  "V"  operate  on  the  "counting 

semaphores"  which  are  variables  that  take  on  integer  values 
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(but  not  just  0  and  1) .  The  mechanisms  can  be  defined  as 
follows: 

P  (S)  : 

1.  Decrement  value  of  S  (i.e.,  S  =  S-l) . 

2.  If  S  is  less  than  0,  WAIT  (S) . 

V(S)  : 

1.  Increment  value  of  S  (i.e.,  S  =  S+l)  . 

2.  If  S  is  less  than  or  equal  to  0,  SIGNAL  (S) . 

WAIT  and  SIGNAL  are  primitives  of  processor  manage 
ment.  A  WAIT  (S)  sets  the  process  to  the  blocked  state  and 
links  it  to  the  lock  byte  S.  Another  process  is  then  selected 
to  run  by  the  process  scheduler.  A  SIGNAL  (S)  checks  the 
blocked  list  associated  with  lock  byte  S.  If  there  are  any 
processes  blocked  waiting  for  S,  one  is  selected  and  is  set 
to  the  ready  state.  Then  the  scheduler  will  select  a  process 
to  run. 

In  order  to  implement  semaphores  in  the  system, 
the  processor  multiplexing  algorithm  must  be  informed  of  all 
"V"  operations  to  semaphores,  and  must  keep  track  of  the  set 
of  virtual  processors  that  are  waiting  for  each  semaphore  to 
indicate  that  the  event  has  occurred. 

Unfortunately  semaphores  have  several  disadvantage 
First,  they  are  limited  to  cases  where  the  occurrence  of  an 
event  will  allow  a  fixed  number  of  virtual  processors  to 
proceed  out  of  the  waiting  state.  (This  mechanism  has  no 
"broadcast"  capability) .  Second,  because  of  this  limitation, 
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the  ability  to  proceed  past  a  "P"  operation  on  a  semaphore 
automatically  becomes  a  kind  of  scarce  resource  that  can  be 
used  as  a  communication  channel  among  processes  that  wait  on 
the  semaphore . 

This  latter  point  is  quite  important  in  a  secure 
system  design.  Although  communication  of  information  is 
inherent  in  the  inter-process  synchronization  mechanism 
between  the  virtual  processor  that  causes  an  event  and  the 
virtual  processors  that  await  the  occurrence  of  that  event, 
there  is  no  inherent  requirement  that  virtual  processors 
waiting  for  the  same  event  to  occur  should  have  a  communication 
path  among  themselves. 

c .  " Block-Wakeup " 

This  mechanism  described  in  detail  by  Saltzer 

[14]  is  quite  similar.  A  discussion  of  some  problems 

encountered  with  this  mechanism  is  presented  in  [15] . 

Reed  in  his  thesis  [15]  notes: 

"If  virtual  processor  A  can  wake  up  virtual  processor  B, 
there  is  no  guarantee  that  the  reason  virtual  processor  B 
is  waiting  is  the  reason  virtual  processor  A  wakes  B  up. 
Virtual  processor  A's  wakeup  will  then  be  misinterpreted 
by  B,  or  ignored  by  B.  In  the  first  case,  B  will  proceed 
under  the  false  assumption  that  the  event  awaited  happened, 
while  in  the  second  case,  B  will  lose  the  wakeup  (This  is 
the  case  described  by  Saltzer  as  the  "lost  wakeup"  problem) 
even  though  it  may  be  meaningful  to  B  at  a  later  time. 

These  problems  can  be  serious  for  system  security,  if  the 
wakeups  are  intended  for  a  protected  system  operation  in 
B's  virtual  processor,  because  a  wait  operation  executed 
outside  of  the  protected  part  of  the  system  can  receive 
inter-process  synchronization  signals  intended  for  the 
protected  part.  The  arrival  of  an  inter-process  synchro¬ 
nization  signal  can  carry  privileged  system  information. 
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An  unprotected  receiver  may  either  gain  unauthorized 
access  to  privileged  information,  or  prevent  it  from 
reaching  its  proper  destination.  These  occurrences 
cannot  be  prevented  because  B  is  multiplexing  the  meaning 
of  his  wakeup-waiting  switch,  and  so  must  allow  A  to  wake 
him  up  at  all  times,  even  though  B  waits  for  A's  event 
only  sometimes" . 

For  these  reasons,  along  with  the  need  to  deal 
with  synchronization  in  "distributed"  systems,  Kanodia  and 
Reed  [10]  have  designed  an  inter-process  synchronization 
mechanism  that  is  in  some  sense  more  general  than  either 
semaphores  or  block-wakeup,  and  uses  "Eventcounts"  and 
"Sequencers".  We  shall  discuss  eventcounts  and  sequencers 
later  on  in  this  Chapter. 

6 .  Communication  and  Synchronization  In  This  Implementation 
a .  Introduction 

The  design  of  this  operating  system  supports  multi¬ 
programming  and  multiprocessing.  Multiprogramming  is  used  to 
improve  system  efficiency  and  to  create  a  virtual  environment 
which  frees  the  remainder  of  the  operating  system  from  a 
dependence  on  the  physical  processor  configuration.  On  the 
other  hand  the  process  structure  provides  the  essentials  for 
parallel  (concurrent)  processing.  In  a  multiprocessor 
environment  concurrent  processing  can  provide  faster  comple¬ 
tion  of  a  job.  Using  n  processors  working  on  the  same  job 
and  each  of  them  doing  separate  -asks  (after  a  suitable 
partitioning  of  the  job) ,  the  overall  time  required  to  run 
the  job  can  be  reduced,  frequently  by  a  factor  n. 
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The  above  discussion  provides  some  of  the  major 
reasons  why  this  system  is  designed  to  support  concurrent 
processing  on  multiple  processors.  In  addition,  the 
existence  of  multiple  physical  processors  gave  rise  to  the 
need  for  the  design  of  processor  multiplexing  to  be  done  in 
two-levels.  The  Traffic  Controller  that  multiplexes  processes 
among  virtual  processors  and  the  Inner  Traffic  Controller 
that  multiplexes  physical  processors  among  a  fixed  larger  set 
of  virtual  processors. 

Since  this  system  will  also  be  used  to  support 
real-time  processing,  a  pre-emption  mechanism  is  provided  to 
facilitate  preemptive  scheduling. 

The  above  process  multiplexing,  processor  multi¬ 
plexing,  and  preemptive  scheduling  require  the  following 
support  in  communication  and  synchronization: 

(1)  Inter-process  communication  and  synchroniza¬ 
tion,  at  the  Traffic  Controller  level. 

(2)  Inter-virtual  processor  communication  and 
synchronization  at  the  Inner  Traffic  Controller  level. 

(3)  Inter-real  processor  communication  needed  to 
support  the  preemptive  scheduling . 

b.  Inter-Process  Communication  and  Synchronization 

For  concurrent  processing,  a  job  composed  of 
sequential  and  non- sequential  tasks,  is  explicitly  divided 
(partitioned)  into  an  appropriate  structure  of  processes 
that  can  run  concurrently.  There  is  the  possibility  that 
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after  the  partitioning  the  resulting  processes  must  interact 
(need  cooperation) . 

It  is  the  responsibility  of  the  operating  system 
to  provide  mechanisms  for  communication  and  synchronization 
between  cooperating  processes.  There  are  two  different  kinds 
of  interaction  that  processes  must  be  able  to  achieve. 

First  there  must  exist  a  way  for  processes  to 
exchange  data.  This  mode  of  communication  is  called  "inter¬ 
process  communication" .  In  a  computer  system  that  allows 
sharing  of  memory  segments  between  processes  (in  our  case 
shared  segments  will  reside  in  the  "global"  memory  board) , 
there  is  no  need  for  a  special  inter-process  communication 
facility  to  be  built  into  the  processor  multiplexing  algorithm. 
Shared  memory  segments  provide  an  extremely  high  bandwidth 
data  communication  channel  between  the  processes  sharing 
these  segments.  Any  protocol  for  inter-process  communication 
can  be  established  by  the  processes  using  the  shared  segments. 
Therefore  the  inter-process  communication  will  be  handled 
outside  of  the  scope  of  this  thesis.  The  responsibility  is 
left  to  the  user  of  the  operating  system,  since  it  is  dependent 
on  the  specific  application  program. 

Secondly  there  must  exist  a  way  for  processes  to 
wait  for  data  prepared  by  other  processes  and  for  processes 
that  prepare  such  data  to  signal  that  this  data  is  available. 
This  interaction  is  different  than  communication  of  data  and 
is  called  "inter-process  synchronization".  Together  they  are 


called  "inter-process  communication  and  synchronization". 
Another  term  for  inter-process  synchronization  is  "inter¬ 
process  control  communication"  since  the  effect  of  such 
communication  is  purely  to  reenable  a  waiting  control  point. 

The  actual  coordination  is  realized  inside  the 
kernel  by  the  use  of  "shared  writable"  segments  and  is  used 
for  controlling  the  execution  of  processes  and  coordinating 
the  sharing  of  data. 

The  synchronization  between  processes  is  "visible" 
to  the  user  and  is  supported  by  the  TC$ AWAIT  and  TC$ ADVANCE 
that  are  kernel  calls  to  the  Traffic  Controller  level.  We 
have  already  discussed  the  basics  of  these  two  synchronization 
primitives  in  paragraphs  C6a,  C7a  and  D  of  Chapter  II.  The 
details  are  described  in  the  corresponding  modules  of  the 
Traffic  Controller  in  this  chapter. 

The  inter-process  synchronization  is  intimately 
related  to  the  structure  of  the  "processor  multiplexing 
mechanism" .  The  ability  of  a  process  to  indicate  that  it 
does  not  need  virtual  processor  resources  until  a  particular 
"event"  happens  is  basic  to  the  economic  advantage  of  process 
multiplexing  among  virtual  processors. 

c.  Inter-virtual  Processor  Communication  and  Synchro¬ 
nization 

The  ability  of  a  virtual  processor  to  indicate 
that  it  does  not  need  real  processor  resources  until  a  parti¬ 
cular  "event"  happens  is,  similarly,  basic  to  the  economic 
advantage  of  virtual  processors  multiplexing  among  real 
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processors.  Otherwise  if  a  dedicated  real  processor  is 
actually  available  for  each  virtual  processor,  then  the  "busy¬ 
waiting"  would  be  an  adequate  mechanism  for  synchronization. 
("Busy-waiting"  is  repeatedly  testing  the  state  of  a  shared 
memory  word  in  a  loop) . 

If  for  example,  a  user  process  calls  upon  some 
system  service,  such  as  a  disk  I/O  or  an  I/O  for  a  real-time 
sensor,  it  must  wait  for  that  service  to  be  completed  before 
it  can  proceed.  (The  performance  of  a  system  service  is,  in 
this  case,  considered  to  be  part  of  the  requesting  process) . 
However,  the  service  may  actually  be  supported  by  another 
virtual  processor.  To  control  this  interaction,  the  Inner 
Traffic  Controller  that  multiplexes  physical  processors  among 
virtual  processors,  provides  the  required  inter-virtual 
processor  communication  and  synchronization  mechanism  using 
the  primitives  ITC$AWAIT  and  ITC$ADVANCE. 

We  have  already  discussed  the  basics  of  these  two 
synchronization  primitives  in  paragraphs  C6b,  C7b  and  D  of 
Chapter  II.  The  details  are  described  in  the  corresponding 
modules  of  the  Inner  Traffic  Controller  in  this  chapter. 

This  inter-virtual  processor  synchronization  is 
"invisible"  to  the  user,  and  is  used  by  the  operating  system 
for  the  management  of  physical  resources.  This  mechanism 
provides  the  solution  to  a  difficult  problems  "the 
synchronization"  that  will  be  faced  later  on,  when  the 
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"Memory  Management"  and  "I/O  Management"  are  added  to  the 
operating  system. 

d.  Inter-Real  Processor  Communication 

To  support  real-time  processing  we  need  the 
preemptive  scheduling.  Since  we  are  working  in  a  multiple- 
processor  environment  the  operating  system  has  to  support  an 
inter-real  processors  communication  mechanism,  which  is  of 
course  related  to  the  inter-virtual  processors  synchronization 
mechanism.  It  will  be  explained  by  the  two  examples  below. 

It  is  important  to  note  that  the  preemptive 
scheduling  mechanism  is  completely  distinct  from  the  synchro¬ 
nization  mechanism  and  its  purpose  is  to  cause  the  "immediate 
attention"  of  a  real  processor  when  it  is  needed  for  real 
time  applications. 

The  TC$ADVANCE  and  ITC$ADVANCE  modules  provide 
a  "broadcast"  capability.  Let  us  examine  first  the  case  of 
TC$ADVANCE.  When  an  application  (user)  process  calls  the 
TC$ ADVANCE ,  the  result  is  an  incrementing  by  one  of  the 
associated  event's  current  value.  This  change  of  the  event's 
value  is  "broadcast"  to  all  processes  that  are  awaiting  this 
value  for  the  specific  event.  We  have  to  remember  here  that 
the  operating  system  is  distributed  to  each  Real  Processor 
and  also  that  each  real  processor  in  this  implementation 
possesses  four  virtual  processors.  If  a  process  waiting  for 
the  above  specific  event  is  bound  to  a  Virtual  Processor 
which  belongs  to  another  real  processor,  then  there  is  no  way 
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to  signal  that  virtual  processor  to  inform  it  of  the  occurrence 
of  this  event.  Similarly,  if  during  the  physical  resources 
management  (for  example  I/O  management)  the  ITC$ADVANCE  is 
invoked  by  the  operating  system  (this  is  "invisible"  to  the 
user) ,  it  results  again  in  an  incrementating  by  one  of  the 
associated  event's  current  value  (now  in  the  Inner  Traffic 
Controller  level) .  If  this  change  has  to  be  "broadcast"  to 
a  Virtual  Processor  awaiting  this  event  and  the  Virtual 
Processor  belongs  to  another  Real  Processor,  then  again  there 
is  no  way  to  inform  that  Virtual  Processor  of  the  occurrence 
of  the  specific  event. 

\ 

To  facilitate  the  inter-real  processor  communica¬ 
tion,  we  employ  the  hardware  interrupt.  Similar  to  most 
microcomputers,  the  8086  microprocessor  does  not  have  the 
capability  to  send  hardware  interrupts  destined  for  other 
devices  (here  the  devices  of  interest  are  other  CPU's).  To 
solve  the  problem  we  have  suitably  configured  the  hardware 
using  the  on  board  (8086  microcomputer)  hardware  chips,  8259A 
Programmable  Interrupt  Controller  and  8255A  Programmable 
Peripheral  Interface  and  the  Multibus  interface. 

This  configuration  is  discussed  in  detail  in 
paragraph  G  of  this  chapter. 

e.  Events,  Eventcounts,  and  Sequencers 

The  ability  to  synchronize  the  execution  of  pro¬ 
cesses  throughout  the  system  (irrespective  of  which  micro¬ 
computer  they  are  loaded  on)  is  the  cornerstone  of  the  power 


and  flexibility  of  this  system.  To  accomplish  this,  process 
synchronization  is  based  on  the  notion  of  "events". 

An  "event”  is  anything  that  one  considers  signif¬ 
icant  and  can  direct,  in  some  fashion,  the  computer  to  respond 
to.  For  example  events  of  interest  are:  the  completion  of  a 
program,  a  buffer  becomes  full  or  empty,  a  printer  is  ready, 
a  process  in  execution  on  a  VP  reaches  a  control  point  defined 
by  the  user.  More  generally,  the  events  can  represent  virtually 
anything  of  interest  to  the  programmer. 

When  an  event  occurs,  the  computer  recognizes  that 
it  is  to  respond  in  some  specified  manner. 

"Eventcounts"  and  "sequencers"  allow  processes  to 
synchronize  with  each  other  somewhat  indirectly.  To  synchronize 
directly,  a  process  would  have  to  somehow  identify  the  other 
processes  with  which  it  is  synchronizing  (viz.,  explicitly 
signal  a  process  by  name) .  This  would  require  the  naming  of 
individual  processes  or  some  similar  identification  scheme. 

Rather  than  using  a  process  naming  scheme,  the 
individual  processes  "agree",  in  a  sense,  to  cooperate  by 
using  a  common  set  of  memory  objects  called  eventcounts  and 
sequencers.  In  this  way,  even  though  the  processes  must  know 
the  names  of  the  eventcounts  and  sequencers  that  they  use, 
they  are  not  required  to  know  anything  at  all  about  each 
other's  identities.  In  fact,  a  process  need  not  even  know 
how  many  other  processes  will  be  synchronizing  with  it.  This 
offers  some  advantages  in  parallel  processing.  Processes  that 
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synchronize  with  eventcounts  do  not  have  to  know  how  many  other 
processes  will  also  use  the  same  eventcounts.  This  means  that 
fewer  coding  changes  will  be  required  when,  for  example,  a 
single  process  is  partitioned  into  several  processes  all 
executing  in  parallel.  All  of  the  "new"  processes  will 
synchronize  on  the  same  eventcount  so  that  no  changes  are 
required  in  the  process  that  originally  synchronized  with  the 
single  process. 

Eventcounts  are  used  to  keep  track  of  the  occurrence 
of  specific  events.  They  are  managed  for  the  user  by  the 
system.  Sequencers  can  be  used  to  impose  a  linear  order  on 
the  occurrence  of  events.  They  are  thus  used  with  event- 
counts  to  provide  for  mutual  exclusion, 
f .  Eventcounts 

"Eventcounts"  are  used  in  this  implementation  to 
allow  processes  to  arbitrate  access  to  shared  resources.  An 
eventcount  is  defined  by  Reed  [10]  as:  "An  eventcount  is  an 
object  in  the  system  that  represents  a  class  of  events  that 
will  eventually  occur".  Each  eventcount  represents  a  distinct 
class  of  events.  This  class  of  events  is  ordered  so  that  by 
the  time  event  H  occurs  all  events  numbered  from  0  to  N-l  will 
have  occurred.  Consequently,  the  set  of  events  that  have 
occurred  at  any  particular  time  can  be  represented  by  the 
number  of  the  last  event  to  occur.  This  number  is  known  as 
the  "current  value"  of  the  eventcount. 


An  eventcount  is  associated  with  some  type  of  event 
of  interest,  e.g.,  occurrence  of  a  real-time  interrupt,  a  data 
segment  being  read  or  written  into,  etc.  Eventcounts  are 
implemented  as  sets  of  positive  integers  from  0  to  infinity 
(the  current  limit  in  this  implementation  is  actually  65,536 
using  PL/M-86  "word”  variables  which  is  "adequate"  for  the 
applications  anticipated)  and  are  used  to  keep  track  of  the 
total  number  of  such  events  that  have  occurred. 

The  eventcount  synchronization  mechanism  has  the 
useful  property  that  two  virtual  processors  waiting  for  events 
in  the  same  class  (thus  recorded  in  the  same  eventcount)  do 
not  have  an  inherent  intercommunication  path.  The  enabling  of 
one  virtual  processor  to  proceed  does  not  automatically  disable 
any  other  virtual  processors  from  proceeding  and  allows 
broadcasting  events  to  multiple  virtual  processors.  This  is 
a  function  not  easily  achieved  using  semaphores.  Consequently, 
this  mechanism  is  more  desirable  for  use  in  a  secure  system  to 
address  the  "confinement  property".  Further,  the  implementa¬ 
tion  of  eventcounts  is  not  inherently  more  difficult  than 
that  of  semaphores . 

There  are  three  operations  which  may  be  performed 
on  eventcounts,  as  follows: 

(1)  "Read"  Operation.  The  current  value  of  an 
eventcount  may  be  obtained  by  the  READ  operation.  This  oper¬ 
ation  returns  the  present  value  of  the  eventcount  as  a  "positive 
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integer"  n.  From  this  value,  one  may  infer  that  events  0  to  n 
have  already  occurred.  TC$READ  (Traffic  Controller  READ)  in 
the  present  implementation  is  a  function  call  in  the  Traffic 
Controller  Level  available  ("visible")  to  the  user  via  the 
"GATE"  so  that  it  will  provide  him  the  capability  to  obtain, 
the  current  value  of  the  eventcount  of  interest  specified 
in  the  call.  Details  will  be  discussed  in  the  corresponding 
module  of  the  Traffic  Controller  later  in  this  chapter. 

(2)  "AWAIT"  Operation.  Allows  the  calling  subject 
to  await  a  particular  event  in  the  class  associated  with  the 
eventcount.  This  operation  requires  that  the  event  name  and 
the  awaited  eventcount  value  be  specified.  Particularly  in 
the  present  implementation  there  are  two  procedures  as  follows: 

TC$ AWAIT  (  Traffic  Controller  AWAIT)  is  an 
inter-process  synchronization  primitive.  Allows  a  process  (the 
"calling"  process)  to  suspend  its  own  execution  (enter  the 
"blocked"  state)  until  the  event  specified  in  the  input  argu¬ 
ment  (by  name  and  value)  has  occurred,  viz.,  the  eventcount 
reaches  the  specified  awaited  value.  The  result  is  that  the 
process  will  "give  away"  the  virtual  processor  to  which  it  is 
bound.  The  effect  of  this  operation  is  similar  as  the  conven¬ 
tional  Saltzer's  "Block"  operation  or  Dijkstra's  "P"  operator 
(on  counting  semaphores). 

TC$ AWAIT  is  a  procedure  in  the  Traffic 
Controller  Level  "visible"  to  the  user  via  the  "GATE" .  Details 
will  be  discussed  in  the  corresponding  module  of  the  Traffic 
Controller  later  in  this  chapter. 


119 


ITC$AWAIT  (Inner  Traffic  Controller  j^WAIT)  ,  is 
an  inter-virtual  processor  synchronization  primitive.  It 
suspends  the  execution  of  the  "running"  virtual  pi«ocessor 
(setting  its  state  to  "waiting")  until  the  event  specified 
(by  name  and  value)  in  the  input  argument  has  occurred,  viz., 
the  eventcount  reaches  the  specified  awaited  value.  This 
synchronization  primitive  is  used  by  the  Inner  Traffic 
Controller  for  the  management  of  system  resources.  ITC$AWAIT, 
"invisible"  to  the  user,  and  is  used  only  by  the  operating 
system.  Details  will  be  discussed  in  the  corresponding  module 
of  the  ITC  later  in  this  chapter. 

TC $ AWAIT/ ITC$ AWAIT  will  prevent  the  process/ 
virtual  processor  respectively  from  proceeding  until  the 
current  value  of  the  eventcount  reaches  the  awaited  event 
value  specified  in  the  procedure's  call. 

(3)  "ADVANCE"  Operation.  This  operation  informs 
the  processor  multiplexing  mechanism  of  the  new  value  of  the 
advanced  eventcount  and  requires  that  the  event  name  be 
specified  as  an  argument.  Particularly  in  this  implementation 
there  are  two  procedures  as  follows: 

TC$ ADVANCE  (Traffic  Controller  ADVANCE)  is  an 
inter-process  synchronization  primitive.  A  TC$ ADVANCE  opera¬ 
tion  is  performed  by  a  process  when  an  event  has  occurred.  It 
increments  the  current  value  of  the  specified  eventcount  by 
one  to  reflect  the  occurrence  of  the  event.  This  has  the 
effect  of  signalling  the  event's  occurrence  to  other  processes 
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which  were  waiting  for  it  by  virtue  of  having  previously  per¬ 
formed  an  AWAIT  operation  on  that  event.  The  effect  of  an 
ADVANCE  operation  is  essentially  the  same  as  a  Saltzer's 
Wakeup  operation  of  Dijkstra's  "V"  operator  (on  counting 
semaphores) . 

The  eventcount  signalling  mechanism  has  an 
"automatic  broadcast  effect"  which  offers  an  advantage  in 
parallel  processing.  This  broadcast  capability  allows  the 
"simultaneous  signalling"  of  several  processes  which  otherwise 
would  have  to  be  signalled  "sequentially". 

TC$ ADVANCE  is  a  procedure  in  the  Traffic 
Controller  Level  "visible"  to  the  user  via  the  "GATE". 
TC$ADVANCE  is  also  in  this  implementation  responsible  for 
the  "preemptive  scheduling".  Details  will  be  discussed  in 
the  corresponding  module  of  the  Traffic  Controller  later  in 
this  chapter. 

ITC$ ADVANCE  (Inner  Traffic  Controller 
ADVANCE) ,  is  an  inter-virtual  processor  synchronization 
primitive.  Signals  that  the  specified  in  the  call  event 
(event's  name  is  the  input  argument)  has  occurred  by  advanc¬ 
ing  (incrementing  by  one)  the  value  of  the  associated 
eventcount.  This  eventcount  signalling  mechanism  has  also 
an  "automatic  broadcast"  effect  which  offers  an  advantage  in 
parallel  processing.  All  the  virtual  processors  awaiting 
the  occurrence  of  this  specific  event  are  informed. 

I TC$ ADVANCE  is  a  procedure  in  the  Inner  Traffic  Controller 
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Level  "invisible"  to  the  user  and  is  used  only  by  the  opera¬ 
ting  system  for  the  management  of  system's  resources. 

Details  will  be  discussed  in  the  corresponding  module  of  the 
ITC  later  in  this  chapter, 
g.  Sequencers 

There  are  many  situations  where  accesses  to 
shared  resources  must  be  totally  ordered.  Eventcounts  alone 
are  not  sufficient  to  accomplish  this.  To  provide  the 
capability  for  mutual  exclusion,  another  type  of  object 
called  a  "sequencer"  [10]  is  employed.  A  sequencer  is 
implemented  as  a  positive  integer  ranging  in  value  from  0  to 
infinity  (as  with  eventcounts,  the  current  limit  in  this 
implementation  is  65,536).  However,  a  sequencer  is  used  to 
provide  total  order  to  the  occurrence  of  events. 

A  sequencer  is  also  necessary  to  solve  the 
confinement  and  readers/writers  problems.  Some  synchroniza¬ 
tion  problems  require  arbitration,  e.g.,  two  write  accesses 
to  the  same  segment.  Eventcounts  alone  as  already  discussed 
do  not  have  the  ability  to  discriminate  between  two  events 
that  happen  in  an  uncontrolled  (i.e.,  concurrent)  manner. 

Initially  a  sequencer  has  a  value  of  0.  The  value 
increases  by  one  each  time  a  "TICKET"  operation  is  performed 
on  it.  TICKET  is  the  only  operation  defined  on  a  sequencer. 
TICKET  returns  a  unique  monotonically  increasing  value  with 
each  call.  It  is  similar  to  getting  a  ticket  and  waiting  to 
be  served  at  a  restaurant.  Two  uses  of  TICKET  will  return 
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two  different  values  corresponding  to  the  "relative  time"  of 
call.  Thus,  a  set  of  events  can  be  totally  ordered  by  using 
the  TICKET  operation.  Details  about  TICKET  operation  will  be 
discussed  in  the  corresponding  module  of  the  TC  later  in  this 
chapter. 

G.  INTERRUPT  STRUCTURE 
1 .  Introduction 

The  operating  system  has  to  control  a  multiple- 
processor  environment.  This  generates  the  need  of  some  method 
of  communication  between  physical  processors.  This  need  is 
satisfied  by  an  ability  to  generate  hardware  interrupts 
between  the  physical  processors.  The  interrupts  are  used 
for  the  implementation  of  "preemptive  scheduling".  INTEL'S 
8086  microprocessor,  as  most  microprocessors,  doesn't  possess 
the  capability  to  directly  generate  interrupts  destined  for 
other  devices  (the  devices  of  interest  here  are  other 
processors) .  We  provide  that  capability  by  suitably  configur¬ 
ing  the  hardware  and  using  some  software  control.  Note  that 
only  a  "single"  interrupt  line  is  actually  used  to  implement 
sy3tem-wide  preempt  interrupts.  This  is  the  only  hardware 
configuration  adaptation  to  facilitate  the  operating  system 
and  we  are  going  to  describe  it  in  detail. 

The  system's  interrupt  structure  is  managed  by  the 
Inner  Traffic  Controller.  In  particular,  a  physical  system 
interrupt  is  transformed  into  a  synchronization  signal  to  a 
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waiting  virtual  processor.  This  structure  is  particularly 
important  for  the  support  of  real-time  processing  and  note 
that  this  is  completely  distinct  from  inter-process  synchro¬ 
nization  and  communication. 

To  implement  this  desired  configuration  we  use  the 
8259A  PIC  (Programmable  Interrupt  Controller)  and  8255A  PPI 
(Programmable  Peripheral  Interface) ,  both  on  board  on  the 
86/12A  microcomputer. 

The  8086  instructions  support  two  types  of  interrupts, 
external  and  internal  (or  "trap") .  An  external  interrupt  is 
initiated  by  some  peripheral  asserting  an  interrupt  request 
to  the  8086  in  the  hardware.  An  internal  interrupt  is  one 
initiated  by  the  software  the  8086  is  executing.  An  inter¬ 
rupt  represents  a  transfer  of  program  execution  control.  The 
type  of  transfer  used  in  the  3086  is  called  a  vectored 
interrupt.  An  interrupt  vector  represents  an  address  of  a 
procedure  which  services  the  interrupt. 

In  the  8086  all  interrupts  (both  external  and 
internal)  perform  a  transfer  by  pushing  the  flag  registers 
onto  the  stack  (as  in  PUSHF) ,  and  then  performing  an  indirect 
call  (of  the  intersegment  variety)  through  an  element  of  an 
interrupt  vector  located  at  absolute  memory  locations  0  through 
3FFH.  Each  vector  is  a  four  byte  element  with  the  first  two 
bytes  containing  the  offset  of  a  procedure  (or  label)  and  the 
second  two  bytes  containing  the  paragraph  number  of  the 
segment  containing  the  procedure  (or  label) .  There  are  256 
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possible  interrupt  vectors.  Within  the  8086  assembly 
language,  each  vector  is  given  a  number  from  0  through  255. 
Interrupts  0  through  4  (0-13H)  currently  have  the  dedicated 


hardware  functions  as 

defined  on  Figure 

29  below  (the  dedica- 

tion  has  been  made  by 

INTEL  Corporation) 

• 

Interrupt  # 

Location 

Function 

0 

0-03H 

divide  by  zero 

1 

04H-07H 

single  step 

2 

08H-0BH 

non-maskable  interrupt 

3 

0CH-0FH 

one  byte  interrupt 
instruction  (INT  3) 

4 

10H-13H 

interrupt  on  overflow 

FIGURE  29.  INTERRUPTS  0  to  4 . 

There  are  three  interrupt  transfer  operations  provided: 

-  INT  pushes  the  flag  registers,  clears  the  TF  (Trap  Flag) 
and  IF  (Interrupt  Flag)  flags,  and  transfers  control 
with  an  indirect  call  through  any  of  the  256  vector 
elements,  i.e.,  INT  24  will  do  an  indirect  call 
through  interrupt  vector  24  (location  96) .  A  one  byte 
form  of  this  instruction  is  available  for  interrupt 
type  3,  INT  3.  We  use  INT  instruction  for  the 
implementation  of  the  "GATE" . 

-  INTO  pushes  the  flag  registers,  clears  the  TF  and  IF 
flags  and  transfers  control  through  vector  element  4 
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if  the  OF  flag  is  set  (interrupt  on  overflow) .  If 
the  OF  flag  is  cleared,  then  no  operation  takes  place. 

-  IRET  transfers  control  to  the  return  address  saved  by 
a  previous  interrupt  operation  and  restores  the  saved 
flag  registers.  This  instruction  is  used  several 
times  for  the  implementation  of  the  operating  system. 

For  external  interrupts,  the  peripheral  device  will  request 
an  interrupt  from  the  8086.  When  the  8086  grants  the  inter- 
rupt,  the  device  will  supply  a  byte  value  on  the  data  bus 
which  represents  the  type  or  number  of  the  interrupt  i.e., 

0  through  255.  The  8086  will  read  this  value  and  then 
execute  the  interrupt  through  the  vector. 

2 •  Hardware  Interrupts 

The  8086  CPU  includes  two  hardware  interrupt  inputs, 
NMI  and  INTR,  classified  as  non-maskable  and  maskable, 
respectively. 

a.  Non-Maskable  Interrupt  (NMI) 

The  NIM  input  has  the  higher  priority  of  the  two 
interrupt  inputs.  A  low-to-high  transition  on  the  NMI  input 
will  be  serviced  at  the  end  of  the  current  instruction  or 
between  whole  moves  of  a  block- type  instruction.  Worst-case 
response  to  NMI  is  during  a  multiply,  divide,  or  variable 
shift  instruction. 

When  the  NMI  input  goes  active,  the  CPU  performs 
the  following: 
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(1)  Pushes  the  Flag  registers  onto  the  stack 
(same  as  a  PUSHF  instruction) . 

(2)  If  not  already  clear,  clears  the  Interrupt 
Flag  (same  as  a  CLI  instruction) .  This 
disables  maskable  interrupts. 

(3)  Transfers  control  with  an  indirect  call 
through  vector  location  00008. 

The  NMI  input  is  intended  only  for  catastrophic 
error  handling  such  as  a  system  power  failure.  Upon 
completion  of  the  service  routine,  the  CPU  automatically 
restores  the  flags  and  returns  to  the  main  program, 
b.  Maskable  Interrupt  ( INTR) 

The  INTR  input  has  the  lower  priority  of  the  two 
interrupt  inputs.  A  high  level  on  the  INTR  input  will  be 
serviced  at  the  end  of  the  current  instruction  or  at  the  end 
of  the  whole  move  for  a  block-type  instruction. 

When  INTR  goes  active,  the  CPU  performs  the 
following  (assuming  the  Interrupt  Flag  is  set) : 

(1)  Issues  two  acknowledge  signals.  Upon  receipt 
of  the  second  acknowledge  signal,  the 
interrupting  device  (master  or  slave  PIC) 
will  respond  with  a  one-byte  interrupt 
identifier . 

(2)  Pushes  the  Flag  registers  onto  the  stack 
(same  as  a  PUSHF  instruction) . 

(3)  Clears  the  Interrupt  Flag  thereby  disabling 
further  maskable  interrupts. 

(4)  Multiplies  by  four  (4)  the  binary  value  (X) 
contained  in  the  one-byte  identifier  from 
the  interrupting  device. 

(5)  Transfers  control  with  an  indirect  call 
through  location  4X. 
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Upon  completion  of  the  service  routine,  the  CPU 
automatically  restores  its  flags  and  returns  to  the  main 
program. 

3 .  8259A  PIC  (Programmable  Interrupt  Controller) 

The  on  board  8259A  PIC  functions  as  an  overall 
manager  in  an  interrupt-driven  system  environment.  It  accepts 
requests  from  the  peripheral  equipment,  determines  which  of 
the  incoming  requests  is  of  the  highest  importance  (priority) , 
ascertains  whether  the  incoming  request  has  a  higher  priority 
value  than  the  level  currently  being  serviced  and  may  issue 
an  interrupt  to  the  CPU  based  on  this  determination. 

The  on  board  master  3259A  PIC  handles  up  to  eight 
vectored  priority  interrupts  and  has  the  capability  of 
expanding  the  number  of  priority  interrupts  by  cascading 
one  or  more  of  its  interrupt  input  lines  with  slave  8259A 
PIC's.  Note  that  slave  PIC's  are  not  used  in  this 
implementation . 

The  basic  functions  of  the  PIC  are  to  (1)  resolve  the 
priority  of  interrupt  requests,  (2)  issue  a  single  interrupt 
request  to  the  CPU  based  on  that  priority,  and  (3)  send  the 
CPU  a  vectored  restart  address  for  servicing  the  interrupting 
device. 

a.  Interrupt  Priority  Modes 

The  PIC  can  be  programmed  to  operate  in  one  of 
the  following  modes: 
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(1)  Nested  Mode 

(2)  Fully  Nested  Mode 

(3)  Automatic  Rotating  Mode 

(4)  Specific  Rotating  Mode 

(5)  Special  Mask  Mode 

(6)  Poll  Mode 

In  this  design  the  Nested  Mode  is  used  and  is 
described  in  the  next  paragraph. 

b.  Nested  Mode 

In  this  mode  the  PIC  input  signals  are  assigned 
a  priority  from  0  through  7 .  The  PIC  operates  in  this  mode 
unless  specifically  programmed  otherwise.  Interrupt  IRO  has 
the  highest  priority  and  IR7  has  the  lowest  priority.  When 
an  interrupt  is  acknowledged,  the  highest  priority  request 
is  available  to  the  CPU.  Lower  priority  interrupts  are 
inhibited,  higher  priority  interrupts  will  be  able  to 
generate  an  interrupt  that  will  be  acknowledged,  if  the  CPU 
has  enabled  its  own  interrupt  input  through  software.  The 
End-Of- Interrupt  (EOI)  command  from  the  CPU  is  required  to 
reset  the  PIC  for  the  next  interrupt. 

Details  for  the  remaining  modes  are  described  in 
Reference  [2] . 

c.  Status  Read 

Interrupt  request  inputs  are  handled  by  the 
following  three  internal  PIC  registers: 
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Interrupt  Request  Register  (IRR)  which 
stores  all  interrupt  levels  that  are 
requesting  service. 

(2)  In-Service  Register  (ISR)  which  stores  all 
interrupt  levels  that  are  being  serviced. 

(3)  Interrupt  Mask  Register  (IMR)  which  stores 
the  interrupt  request  lines  which  are  masked. 

These  registers  can  be  read  by  writing  a  suitable 
command  word  and  then  performing  a  read  operation, 
d.  Initialization  Command  Words 

The  on  board  master  PIC  and  each  slave  PIC 
requires  a  separate  initialization  sequence  to  work  in  a 
particular  mode.  The  initialization  sequence  requires  three 
Initialization  Command  Words  (ICW's)  for  a  signle  PIC  system 
and  requires  four  ICW's  for  a  master  PIC  with  one  to  eight 
slaves.  The  ICW  formats  are  shown  in  Figure  30.  Since  no 
slave  PIC's  are  used  we  shall  describe  below  only  the 
initialization  command  words  needed  to  initialize  the 
on  board  PIC. 

The  First  Initialization  Command  Word  (ICW1) , 
which  is  required  in  all  modes  of  operation  consits  of  the 
following: 

(1)  Bits  0  and  4  are  both  l's  and  identify  the 
word  as  ICW1  for  an  8086  CPU  operation. 

(2)  Bit  1  denotes  whether  or  not  the  PIC  is 
employed  in  a  multiple  PIC  configuration. 

For  a  single  master  PIC  configuration 

(no  slaves)  bit  1*1;  for  a  master  with 
one  or  more  slaves  bit  1=0.  Note  that 
bit  1=0  only  when  programming  a  slave  PIC. 
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ICW1 


ICW4 


NOTE:  X  INDICATED  "DON’T  CARE" 


FIGURE  30.  PIC  INITIALIZATION  COMMAND  WORD  FORMATS 
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(3)  Bit  3  establishes  whether  the  interrupts 

are  requested  by  a  positive-true  level  input 
or  requested  by  a  low-to-high  input.  This 
applies  to  all  input  requests  handled  by 
the  PIC.  In  other  words,  if  bit  3=1,  a 
low-to-high  transition  is  required  to  request 
an  interrupt  on  any  of  the  eight  levels 
handled  by  the  PIC. 

The  second  Initialization  Command  Word  (ICW2) 
represents  the  vectoring  byte  (identifier)  and  is  required 
by  the  8086  CPU  during  interrupt  processing.  ICW2  consists 
of  the  following: 

(1)  Bits  D3-D7  (A11-A15)  represent  the  five  most 
significant  bits  of  the  vector  byte.  These 
are  supplied  by  the  programmer. 

(2)  Bits  D0-D2  represent  the  interrupt  level 
requesting  service.  These  bits  are  provided 
by  the  8259A  during  interrupt  processing. 
These  bits  should  be  programmed  as  0 ' s  when 
initializing  the  PIC. 

Note  that  the  8086  CPU  multiplies  the  vector  byte 
by  four.  This  value  is  then  used  by  the  CPU  as  the  vector 
address. 


Figure  31  lists  the  vector  byte  contents  for 
interrupts  IR0-IR7. 


D7 

D6 

D5 

D4 

D3 

D2 

Dl 

DO 

IR7 

A15 

A14 

A13 

A12 

AlJ 

1 

1 

1 

IR6 

A15 

A14 

A13 

A12 

A13 

1 

1 

0 

IR5 

A15 

A14 

A13 

A12 

All 

1 

0 

1 

IR4 

A15 

A14 

A13 

A12 

All 

1 

0 

0 

IR3 

A15 

A14 

A13 

All 

A10 

0 

1 

1 

IR2 

A15 

A14 

A13 

A12 

All 

0 

1 

0 

IRJ 

A15 

A14 

A13 

A12 

All 

0 

0 

1 

IRO 

A15 

A14 

A13 

A12 

All 

0 

0 

0 

FIGURE  31.  INTERRUPT  VECTOR  BYTE. 
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It  is  important  here  to  notice  that  the  monitor 
of  each  microcomputer  [21]  initializes  the  PIC.  For  testing 
this  hardware  configuration  the  interrupt  line  4  is  connected 
and  the  interrupt  vector  byte  (of  Figure  31)  is  initialized 
(just  for  this  kernel  program)  to  4 OH.  Note  that  the  three 
LSB  bits  (DO,  Dl,  D2)  are  always  initialized  to  0.  For  the 
specific  initialization,  bit  D6=l  and  all  the  rest  are  0. 
Since  the  interrupt  line  4  is  connected,  the  PIC  upon 
receiving  an  interrupt  resolves  the  priority  and  sets  the 
bits  D2=l ,  D1=0,  D0=0  (D2DlD0=100=4 ) .  Therefore,  the 
interrupt  vector  byte  is  set  to  40H+4=44H.  The  8086  CPU 
multiplies  the  interrupt  vector  byte  by  4  and  the  resulting 
value,  110H,  is  the  vector  address.  The  CPU  will  transfer 
control  to  this  address  to  execute  the  interrupt  service 
routine  corresponding  to  the  interrupt  4.  A  pointer  (four 
bytes)  pointing  to  the  starting  point  of  the  interrupt 
service  routine  must  be  located  in  the  physical  absolute 
address  (110H)  corresponding  to  the  received  interrupt. 

Since  both  the  monitor  and  the  kernel  initialize 
the  PIC  there  exists  a  probability  of  conflict  as  follows: 

If  the  first  100  bytes  of  local  RAM  memory  of  every  micro¬ 
computer  will  be  displayed  using  the  monitor's  display 
command,  as  in  Figure  32,  then  we  can  see  that  the  monitor 
uses  12  bytes  (04  to  OF) .  Also  32  bytes  are  occupied 
(80H  to  9FH)  and  these  are  pointers  to  a  single  entry  point 
(pointer  6C  06  00  FE  is  repeated  8  times) .  If  the  interrupt 
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FIGURE  32.  DISPLAY  OF  THE  FIRST  100H  BYTES 


134 


vector  address,  after  the  PIC  initialization,  happens  to  be 
between  80H  and  9FH  the  interrupt  service  routine  pointer 
is  overwritten  by  the  monitor.  The  solution  is  to  substitute 
(using  monitors'  "S"  command)  the  service  routine  vector  in 
place  of  the  monitor's  interrupt  service  routine  vector.  For 
example  if  we  initialize  the  interrupt  vector  byte  of  Figure 
31  with  2 OH  and  use  interrupt  line  4,  then  after  CPU's 
multiplication  by  4,  the  resulting  vector  address  is  24H*4=90H. 
Before  execution  we  have  to  substitute  the  four  bytes  90H  to 
93H  with  the  interrupt  service  routine  pointer. 

If  we  avoid  the  area  (from  80H  to  9FH)  then  there 
is  no  problem.  Also  when  the  operating  system  (instead  of 
the  monitor)  will  be  the  permanent  resident  of  ROM,  this 
problem  will  not  exist.  (See  also  Anderson’s  thesis  [19]). 

Now  the  PIC  initialization  is  continued. 

The  third  initialization  command  word,  ICW3,  is 
not  required  for  this  implementation  since  we  do  not  use 
slave  PIC's. 

The  fourth  Initialization  Command  Word  (ICW4), 
which  is  required  for  all  modes  of  operation,  consists  of 
the  following: 

(1)  Bit  DO  is  a  1  to  identify  that  the  word  is 
for  an  8086  CPU. 

(2)  Bit  Dl  (AEOI)  programs  the  end-of- interrupt 
function.  Code  bit  1=1  if  an  EOI  is  to  be 
automatically  executed  (hardware) .  Code 
Bit  1=0  if  an  EOI  command  is  to  be  generated 
by  software  before  returning  from  the  ser¬ 
vice  routine. 
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(3)  Bit  D2  (M/S)  specifies  if  ICW4  is  addressed 
to  a  master  PIC  or  a  slave  PIC.  For  example, 
code  bit  2=1  in  ICW4  for  the  master  PIC. 

If  bit  D3  (BUF)  is  zero,  bit  D2  has  no 
function. 

(4)  Bit  D3  (BUF)  specifies  whether  the  8259A  is 
operating  in  the  buffered  or  nonbuffered  mode. 
For  example,  code  bit  3=1  for  buffered  mode. 

The  master  PIC  in  an  iSBC  86/12A,  with  or 
without  slaves,  must  be  operated  in  the 
buffered  mode. 

(5)  Bit  D4  (FNM)  programs  the  nested  or  fully 
nested  mode. 

In  summary,  three  ICW's  are  required  to  initialize 
the  on  board  PIC  in  this  implementation,  ICW1,  ICW2  and  ICW4. 
e.  Operation  Command  Words 

After  being  initialized,  the  master  and  slave 
PIC's  can  be  programmed  at  any  time  for  various  operating 
modes.  The  Operation  Command  Word  (OCW)  formats  are  shown 
in  Figure3-15  of  Reference  [2],  The  format  of  the  only  one 
operation  command  word  used  in  this  implementation  (0CW1)  is 
shown  in  Figure  33. 


D 


0 


FIGURE  33.  OPERATION  COMMAND  WORD  #1,  (OCW  1) 
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f.  Addressing 


The  master  PIC  uses  Port  00C0  or  00C2  to  write 
initialization  and  operation  command  words  and  Port  00C4  or 
00C6  to  read  status,  poll  and  mask  bytes.  Addresses  for  the 
specific  functions  are  provided  in  Reference  [2] . 

g.  Initialization 

To  initialize  the  PIC  the  following  steps  must 

be  followed: 

1.  Disable  system  interrupts  by  executing  a  CLI 
(Clear  Interrupt  Flag)  instruction. 

2.  Initialize  master  PIC  by  writing  ICW's  in 
the  following  sequence: 

Write  ICW1  to  Port  OCCO  and  ICW2  to 
Port  00C2 . 

Write  ICW4  to  Port  00C2. 

3.  Enable  system  interrupts  by  executing  an 
STI  (Set  Interrupt  Flag)  instruction. 

h.  Operation 

After  initialization,  the  master  PIC  and  slave 
PIC ' s  can  independently  be  programmed  at  any  time  by  an 
Operation  Command  Word  (OCW)  for  the  following  operations: 

(1)  Auto-rotating  priority. 

(2)  Specific  rotating  priority. 

(3)  Status  read  of  Interrupt  Request  Register 
(IRR) . 

(4)  Status  read  of  In-Service  Register  (ISR) . 

(5)  Interrupt  mask  bits  are  set,  reset,  or  read. 

(6)  Special  mask  mode  set  or  reset. 
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The  details  of  these  Operation  Command  Words  are 
described  in  Reference  [2] .  In  this  implementation,  only  the 
0CW1  is  used  which  has  already  been  described. 

4 .  8255A  PPI  (Programmable  Peripheral  Interface) 

The  three  parallel  I/O  ports  interfaced  to  connector 
Jl  of  the  86/12A  microcomputer  are  controlled  by  an  INTEL 
8255  Programmable  Peripheral  Interface  chip.  Port  A  includes 
bidirectional  data  buffers  and  Ports  B  and  C  include  IC 
sockets  for  installation  of  either  input  terminators  or  out¬ 
put  drivers  depending  on  the  user's  application. 

Default  jumpers  set  the  Port  A  bidirectional  data 
buffers  to  the  output  mode.  Optional  jumpers  allow  the 
bidirectional  data  buffers  to  be  set  to  the  input  mode  or 
allow  any  one  of  the  eight  Port  C  bits  to  selectively  set 
the  Port  A  bidirectional  data  buffers  to  the  input  or  output 
mode. 

Reference  [2]  lists  the  various  operating  modes  for  the 
three  PPI  parallel  I/O  ports.  Note  that  Port  A  (00C8)  can 
be  operated  in  Modes  0,  1,  or  2;  Port  B  (00CA)  can  be 
operated  in  Mode  0  or  1;  Port  C  (OOCC)  can  be  operated  in 
Mode  0 . 

a.  Control  Word  Format 

The  control  word  format  shown  in  Figure  34  is 
used  to  initialize  the  PPI  in  order  to  define  the  operating 
mode  of  the  three  ports.  Note  that  the  ports  are  separated 
into  two  groups.  Group  A  (control  word  bits  3  through  6) 
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defines  the  operating  mode  for  Port  A  (00C8)  and  the  upper 
four  bits  of  Port  C  (OOCC) .  Group  B  (control  word  bits  0 
through  2)  defines  the  operating  mode  for  Port  B  (OOCA)  and 
the  lower  four  bits  of  Port  C  (OOCC).  Bit  7  of  the  control 
word  controls  the  mode  set  flag. 

b.  Addressing 

The  PPI  uses  four  consecutive  even  addresses 
( 00C8  through  OOCE)  for  data  transfer,  obtaining  the  status 
and  control  of  the  PPI  at  Port  C  (OOCC). 

c.  Initialization 

To  initialize  the  PPI,  a  control  word  is  written 
to  the  port  address  OOCE.  In  Figure  34,  an  example  is  given 
for  the  PPI  initialization.  In  this  example,  the  control 
word  is  92H.  This  initializes  the  PPI  as  follows: 

(1)  Mode  Set  Flag  active 

(2)  Port  A  (00C8)  set  to  Mode  0  Input 

(3)  Port  C  (OOCC)  upper  set  to  Mode  0  Output 

(4)  Port  B  (OOCA)  set  to  Mode  0  Input 

(5)  Port  C  (OOCC)  lower  set  to  Mode  0  Output 

d.  Operation 

After  the  PPI  has  been  initialized,  the  operation 
is  completed  by  simply  performing  a  read  or  a  write  to  the 
appropriate  port. 

5 .  The  Actual  Configuration 

a.  Hardware  Connections 

The  hardware  connections  to  implement  this  hardware 
adaptation  are  marked  with  special  comments  in  the  following 
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Figures  36  and  37.  In  Figure  36  (This  is  the  Figure  5-2,  sheet 
9  of  11,  of  Reference  [2])  pin  E9  is  connected  with  pin  E14 . 

This  connection  will  connect  PC7  (bit  7,  e.g.,  the  MSB  of  Port 
"C")  to  the  BUS  INTR  OUT.  Port  "C"  and  BUS  INTR  OUT  line  are 
shown  on  Figure  35. 

In  Figure  37,  (This  is  the  Figure  5-2,  sheet  8  of 
11  of  Reference  [2])  pin  E137  is  connected  with  pin  E142.  This 
connection  will  connect  INTR  4  (interrupt  4  line)  to  the  BUS 
INTR  OUT.  Then  pin  E6  9  is  connected  with  pin  E7"7.  This 
connection  will  connect  BUS  INTR  OUT  to  the  IR4  (interrupt  4) 
input  of  the  8259A  PIC  (Programmable  Interrupt  Controller) ,  via 
the  Interrupt  Matrix.  INTR4 ,  IR4  and  Interrupt  Matrix  are 
shown  in  Figure  35. 

With  the  above  three  jumpers,  we  connected  the  MSB 
(bit  7)  of  Port  "C"  (of  8255A  Programmable  Peripheral  Interface) 
with  IR4  (interrupt  4  input  of  the  8259A  PIC) .  These  connec¬ 
tions  have  to  be  made  on  every  86/12A  microcomputer  in  the 
system. 

We  have  to  note  here  that  interrupt  line  4  is 
selected  arbitrarily.  It  is  possible  to  connect  a  different 
line  or  to  connect  parallel  Port  "A"  or  "B".  We  selected 
"C"  in  order  not  to  interfere  with  the  operations  of  the 
data  ports  "A"  and  "B". 

b.  Software  Control 

In  order  to  receive  an  interrupt  the  8259A  PIC  has 
to  detect  a  "Low  to  High"  transition  in  the  corresponding  input 
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FIGURE  36.  8255A  PPI ,  BUS  INTERRUPT  OUT  SCHEMATIC  DIAGRAM 


INTERRUPT 


« 


( IR  4  in  our  case).  Since  we  already  have  connected  PC 7  (MSB 
of  Port  "C")  with  the  interrupt  line  4,  we  only  need  to  "Reset- 
Set"  that  MSB  by  writing  a  byte  into  the  Parallel 
Port  "C"  (specif ically  to  port  address  "OOCC") . 

Since  the  Port  "C"  is  an  eight  bit  port,  to  reset 
the  MSB  (PC7)  we  can  write  to  Port  "OOCC"  any  number  from  0  to 
79H  (MSB  equal  0) .  To  set  the  MSB  we  can  write  any  number 
from  80H  to  OFFH  (MSB  equal  1) . 

We  also  use  a  "global"  array  of  flags,  called  in 
the  implementation  HDW$INT$FLAG  (Hardware  Interrupt  Flag) . 

HDW$ INT$FLAG  (n)  corresponds  to  the  processor  whose  identifica¬ 
tion  number  (CPU$NUMBER)  equals  n.  Since  this  flag  array  is 
global,  each  physical  processor  can  access  the  flag  of  any 
other  processor  in  the  system. 

This  way  we  establish  an  effective  and  simple 
design  and  implementation  of  the  "inter-physical  processor 
communication"  using  just  "one"  hardware  interrupt  line.  The 
algorithm  is  shown  in  Figure  38.  When  a  processor  #n  needs 
to  preempt  another  processor  #m,  then  it  first  set  its 
corresponding  flag,  e.g.,  HDW$INT$FLAG (m)  =  TRUE  and  after¬ 
wards  sends  a  hardware  interrupt  by  writing  to  Port  address 
"OOCC"  first  a  zero,  then  an  80H  and  finally  a  zero.  This 
way  processor  #n  generates  the  "Low  to  High"  transition  at 
the  interrupt  4  input  (IR  4)  of  the  8259A  PIC  of  "every" 

86/12A  microcomputer  (including  itself)  in  the  system.  Then 
every  processor  jumps  to  the  interrupt  handler  that  first 
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WHEN  PROCESSOR  #n  NEEDS  1 

'0  PREEMPT  PROCESSOR  #m 

'  * 

> 

SETS  HDW$INT$FLAG(m) 

=  TRUE 

> 

1 - 

- - 

SENDS  ACTUALLY  A  HARDWARE  INTERRUPT  AS  FOLLOWS: 

\ 


OUTPUT  (PORT$OOCC)  =  RESET 

OUTPUT  (PORT$OOCC)  =  SET 
OUTPUT  (PORTSOOCC)  =  RESET 


A  "LOW  TO  HIGH" 

TRANSITION  FOR  IR4 

(TRIGGERED  MODE  IS  USED) 


EACH  ONE  PROCESSOR  JUMPS  TO  THE  INTERRUPT  HANDLER  AND 
ASKS  ITSELF  THE  QUESTION: 


+ _ 

1.  SAVES  EXECUTION  POINT 

OF  PREVIOUS  TASK. 

2.  RESETS  ITS  OWN  FLAG. 

3.  CONTINUES  ON  THE 
INTERRUPT  SERVICE 
ROUTINE. 


CONTINUES  ON 
PREVIOUS  TASK 


FIGURE  38.  PREEMPTIVE  HARDWARE  INTERRUPT  ALGORITHM 
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checks  its  own  HDW$INT$FLAG.  If  the  flag  is  not  set,  the 
processor  continues  on  the  previous  task  by  using  the  IRET 
instruction.  Otherwise,  if  the  interrupt  was  destined  for 
it,  this  processor  saves  the  execution  point  of  the  previous 
task,  resets  its  HDW$ INT$FLAG  and  then  continues  on  the 
interrupt  service  routine. 

H.  SYSTEM-WIDE  DATABASES 

The  operating  system  is  "database"  or  "control  table" 
driven.  There  are  several  shared  databases  (shared  segments) 
that  reside  in  the  global  memory  where  any  processor  can 
access  them  to  maintain  and  update  the  shared  control  data 
used  by  the  operating  system. 

1 .  Virtual  Processor  Map  (VPM) 

The  Inner  Traffic  Controller  is  the  physical  resource 
manager.  The  VPM  is  the  principal  global  data  base  that 
maintains  and  updates  the  data  used  by  the  ITC  to  multiplex 
virtual  processors  among  real  processors  and  to  create  the 
extended  instruction  set  that  controls  the  virtual  processor 
operation.  The  VPM  is  a  system  wide  database  and  is  kept  in 
global  memory  (as  a  shared  segment)  to  facilitate  inter- 
virtual  processor  communication  and  synchronization. 

Each  physical  processor  has  its  own  fixed  set  of 
virtual  processors  (four  in  the  current  implementation)  used 
in  multiplexing.  See  Figure  39.  The  first  and  fourth  VP 
(VP$START  and  VP$END)  are  invisible  to  the  TC  level  (invisible 
to  the  user  processes)  and  are  permanently  bound  to  the  memory 
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management  process  and  idle  process  respectively.  The  VP$START 
has  the  highest  priority  (0  in  this  implementation)  and  the 
VP $ END  the  lowest  (255  or  FFH) .  The  remaining  two  have 
priority  equal  to  the  priority  of  the  user  processes  bound 
to  them.  In  this  way  the  ITC  recognizes  that  each  real 
processor  possesses  four  VP  while  the  TC  recognizes  only 
two  VP  per  real  processor.  A  virtual  processor  mapping 
among  the  TC  and  ITC  is  needed  to  support  this  different  VP 
view. 

It  is  important  to  understand  that  this  VP  multi¬ 
plexing  among  physical  processors  is  an  economic  way  for  using 
the  physical  processor  and  physical  resources  in  general.  For 
example,  by  binding  permanently  the  MMGT  (Memory  Management 
process)  to  a  VP  and  assigning  to  this  VP  (VP$START)  the 
highest  priority,  the  MMGT  process  will  occupy  (run  on) 
the  physical  processor  each  time  there  is  reason  (e.g. ,  when 
some  system  event  happens  that  requires  a  response  by  the 
MMGT) .  Otherwise  another  VP  runs  on  this  physical  processor 
either  the  idle  process  or  a  user  process.  On  the  other 
hand  if  a  real  processor  was  permanently  bound  to  the  MMGT 
process,  this  physical  resource  would  be  idle  whenever  the 
MMGT  process  has  nothing  to  do. 

It  is  also  important  to  note  that  the  ITC 
executing  on  a  physical  processor  is  primarily  concerned 
only  with  its  set  of  the  four  VP.  However,  the  performance 
of  system-wide  synchronization  requires  access  to  the  remaining 


virtual  processors  as  well,  so  that  signals  may  be  used  to 
alert  other  physical  processors  (we  have  discussed  already 
the  case  of  preemptive  scheduling) .  This  is  accomplished  by 
maintaining  the  Virtual  Processor  Map  as  a  shared  data  base 
containing  entries  for  all  of  the  virtual  processors  in  the 
system.  Making  it  globally  available  facilitates  communica¬ 
tion  between  virtual  processors  on  a  system-wide  scale.  The 
Virtual  Processor  Map  fields  are  shown  in  Figure  40. 

The  VPM  INDEX  starts  from  0  to  the  value  NR$RPS 
*  VPS$PER$CPU-1,  viz . ,  number  of  real  processors  in  the 
system  multiplied  by  the  number  of  virtual  processors  per  real 
processor  (four  in  current  implementation)  minus  1.  This  VPM 
INDEX  represents  a  whole  entry  into  VPM  (a  horizontal  line  in 
Figure  40).  For  example,  VPM(O)  represents  the  first  entry 
(horizontal  line) ,  VPM(l)  the  second  and  so  on. 

The  VP$ID  field  is  used  to  support  the  VP  mapping 
between  the  TC  and  ITC.  Details  will  be  discussed  in  para¬ 
graph  18  of  this  chapter.. 

The  VP $ STATE  (virtual  processor  state)  field 
reflects  the  present  state  of  the  virtual  processor  and  can 
be  any  of  "ready",  "running",  "waiting",  or  "idle".  A  ready 
virtual  processor  is  bound  to  a  process  and  is  in  "contention" 
for  the  physical  processor.  The  running  virtual  processor  is 
that  virtual  processor  which  is  actually  executing  a  process 
on  this  physical  processor.  The  waiting  statt  reflects 
physical  resource  management.  The  idle  state  is  assumed  by 
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a  virtual  processor  which  has  no  process  bound  to  it.  The 
idle  state  prevents  the  assignment  of  useless  (idle)  work  to 
a  physical  processor.  Figure  8  illustrates  the  state  transi¬ 
tions  made  by  the  virtual  processors.  In  paragraph  C7b  of 
Chapter  II  the  possible  transitions  of  state  for  a  VP  are 
described. 

The  VP$PRIORITY  (virtual  processor  priority)  field 
of  the  virtual  processor  is  used  in  scheduling.  The  highest 
priority  runnable  virtual  processor  is  selected  to  run.  This 
priority  is  determined  by  the  priority  of  the  process  bound  to 
the  virtual  processor.  The  VP$START,  which  is  permanently 
bound  to  the  MMGT  process  has  the  highest  priority  (zero)  and 
the  VP $ SEND  the  lowest  priority  (255  or  FFH) . 

The  EVC$AW$ID  (Awaited  Eventcount  Identifier)  and 
EVC$AW$VALUE  ( Eventcount ' s  waited  value)  fields  are  used  in 
Inter-virtual  processor  communication  and  synchronization. 
Details  will  be  discussed  in  the  ITC$AWAIT  and  ITC$ADVANCE 
modules  of  the  ITC  later  on  in  this  chapter. 

The  SS$REG  (Stack  Segment  Register  Value)  field 
defines  the  address  space  of  the  process  bound  to  this  VP. 

It  holds  the  "process  address  space  descriptor"  (analogous  to 
DBR  in  MULTICS) .  The  execution  point  of  the  process  is  stored 
on  the  stack  when  the  process  is  not  actually  running.  This 
SS$REG  is  the  only  value  which  is  required  to  access  the 
address  space  of  the  process,  viz.,  it  is  changed  to  swap 
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processes. 
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The  PE$PEND  (Preempt  Pending  Flag)  field  is  used 
for  preemptive  scheduling.  It  serves  to  transform  a  hardware 
interrupt  sent  to  the  physical  process  into  a  virtual  preempt 
interrupt. 

2 .  Active  Process  Table  (APT) 

The  Traffic  Controller  multiplexes  user  (or  applica¬ 
tion)  processes  among  virtual  processors.  In  this  way  the  TC 
is  responsible  to  manage  the  execution  of  user  processes 
("processes  management").  It  is  noted,  one  more  time,  that 
since  the  processes  are  assigned  to  virtual  processors  (and 
not  real  processors) ,  there  is  no  effect  on  the  user  when 
real  processors  are  added  or  deleted  in  the  system,  except, 
of  course,  for  the  change  in  performance.  Most  of  the 
design  and  implementation,  presented  to  the  user,  are  inde¬ 
pendent  of  the  physical  configuration  of  the  system. 

The  Traffic  Controller's  principal  global  data  base 
is  the  Active  Process  Table  (APT) ,  shown  in  Figure  41.  The 
entry  for  each  process  in  the  Active  Process  Table  contains 
sufficient  information  about  the  process  to  enable  a  virtual 
processor  to  be  bound  to  and  execute  it. 

The  APT  INDEX  starts  from  zero  and  grows  as  far  as 
processes  are  loaded  in  the  system.  For  example,  the  APT(O) 
represents  the  first  entry  (horizontal  line)  in  the  APT,  APT(l) 
the  second  and  so  on. 

The  STATE  field  represents  the  state  of  a  process  and 
it  can  be  either  "ready",  "running",  or  "blocked".  A  ready 


153 


FIGURE  41.  APT  (ACTIVE  PROCESS  TABLE) 


process  is  one  which  is  not  yet  bound  to  a  virtual  processor 
but  is  ready  to  do  so  (it  is  in  "contention"  for  VP) .  A 
running  process  is  one  which  is  bound  to  a  virtual  processor 
and,  as  far  as  the  process  is  concerned,  executing.  The 
blocked  state  reflects  inter-process  synchronization.  A  pro¬ 
cess  enters  the  blocked  state  when  it  realizes  that  it  can  no 
longer  proceed  and  wishes  to  "give  up"  its  virtual  processor 
to  wait  until  another  process  awakens  it.  This  is  important 
for  the  economic  advantage  of  virtual  processor  multiplexing 
algorithm,  viz.,  a  process  which  can  no  longer  run,  waiting 
for  the  occurrence  of  an  event  frees  the  virtual  processor 
which  was  bound  to  this  process.  The  possible  states  of  a 
process  and  the  transitions  among  them  are  shown  in  Figure  7 
and  explained  in  paragraph  C7a  of  Chapter  II. 

The  AFFINITY  field  specifies  the  physical  processor 
on  which  the  process  is  currently  loaded.  It  is  possible  to 
change  this  field  during  system  "reconfiguration",  Anderson 
[19]  . 

The  VP$ID  (Identity  Of  Bound  Virtual  Processor)  field 
serves  to  identify  the  virtual  processor,  if  any,  that  the 
process  is  currently  bound  to.  It  is  noted  that  the  user 
processes  are  multiplexed  among  the  two  central  virtual  pro¬ 
cessors  of  each  real  processor  as  shown  in  Figure  39.  The  VP 
with  identification  number  VP$START  and  VP$END  are  invisible 
to  the  TC  and  the  user.  The  necessary  mapping  among  VP$ID  of 
the  ITC  and  TC  will  be  discussed  in  the  ITC$RET$VPTC  module 
in  paragraph  18  in  this  Chapter. 
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The  PRIORITY  field  specifies  the  priority  of  the  process. 
In  this  system,  priorities  range  in  value  from  0  to  255,  with  a 
priority  of  0  being  the  highest.  When  a  process  is  bound  to  a 
VP,  the  VP $ PRIORITY  field  of  the  VPM  corresponding  to  this 
specific  VP,  becomes  equal  to  the  PRIORITY  field  of  the  process. 

The  LOAD$THREAD  (Loaded  List  Thread)  field  serves  to 
implement  the  "Loaded  List"  of  the  ready,  running  and  blocked 
processes.  It  contains  a  pointer  to  the  next  process  in  the 
Active  Process  Table  which  is  loaded  on  the  same  microcomputer 
as  this  process.  The  meaning  of  this  statement  is  that  the 
"loaded  list",  which  is  a  "linked  list",  is  kept  updated  "per 
physical  processor".  A  loaded  process  has  its  address 
space  in  primary  storage;  therefore  it  may  be  scheduled 
to  run  on  a  VP.  In  general,  a  process  can  be  loaded  on 
only  a  single  physical  processor  at  a  time,  due  to  the 
use  of  processor-local  memory.  The  loaded  list  is  ordered 
(sorted)  by  the  priorities  of  the  processes.  Thus  this 
field  contains  either  a  pointer  to  a  process  whose  priority 
is  less  than  or  equal  to  that  of  this  process  or  a  nil 
pointer  (viz.,  the  last  process  on  this  Loaded  List). 

The  EVC$ VALUE  $ AW  (Value  of  Eventcount  Awaited)  field 
reflects  the  event  for  which  the  process  has  blocked  itself. 

It  contains  the  value  that  the  process  is  waiting  for  the 
eventcount  to  reach.  When  this  specific  eventcount  reaches 
this  value  the  process  will  awaken  and  its  state  will  change 
from  "blocked"  to  "ready".  The  usefulness  of  this  field  will 
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be  better  understood  when  describing  the  TC$AWAIT  and  TC$ADVANCE 
modules. 


The  THREAD  (Block  List  Thread)  field  is  used  to  imple¬ 
ment  the  Blocked  List.  This  is  a  "per  eventcount"  linked  list 
of  processes  which  are  waiting  on  the  same  eventcount. 

The  DBR  (Address  Space  Descriptor)  field  contains  the 
process'  address  space  descriptor.  This  is  the  identity  of  the 
process'  stack  which  contains  execution  point  information.  The 
value  used  here  is  the  base  location  in  memory  of  the  stack 
segment,  viz.,  the  Stack  Segment  (SS)  Register  value.  This 
field  is  implemented  exactly  the  same  way  as  the  SS$REG  field 
of  the  VPM. 

Above  we  described  that  the  LOAD$THREAD  field  is  used 
to  implement  a  "per  physical  processor"  linked  list  (the  "load 
list")  of  the  ready,  running,  and  blocked  processes  and  also 
that  the  THREAD  field  is  used  to  implement  a  "per  eventcount" 
linked  list  of  the  blocked  processes  waiting  this  eventcount. 
For  better  understanding  of  these  statements  we  shall  use  an 
example  later  on,  in  paragraph  H6. 

3 .  Eventcount  Table  (EVC$TABLE) 

The  Eventcount  Table  is  also  a  global  data  base  for 
the  TC  level,  as  shown  in  Figure  42  and  is  used  by  the 
inter-process  synchronization  mechanism. 

The  EVC$TABLE  INDEX  starts  from  zero  and  grows  as 
new  events  are  added  in  the  system  by  calls  from  the 
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application  processes.  For  example,  the  EVC$TABLE(0) 
represents  the  first  entry  (horizontal  line)  in  the  EVC$TABLE, 
EVC$TABLE (1)  the  second  and  so  on. 


EVC 

TABLE 

EVC 

EVC 

APT 

INDEX 

NAME 

VALUE 

PTR 

EVC5TABLE  (0) 


EVC5TABLE  (1) 


EVCSTABLE  (2) 


FIGURE  42.  EVC$TABLE  (EVENTCOUNT  TABLE) 

The  EVC$NAME  (eventcount  name)  field  is  a  character 
array  of  six  letters.  The  first  five  letters  is  the  name  given 
to  the  specific  event  by  the  user  and  the  last  letter  is  a 
delimiter  (%  is  used).  This  name  is  used  as  the  input  argument 
of  the  TC $AWAIT  and  TC$ADVANCE  operations. 

The  EVC$VALUE  (Eventcount  value)  field  holds  the 
current  value  of  the  eventcount.  Each  time  a  TC$ADVANCE  oper¬ 
ation  is  executed,  this  value  is  incremented  by  one.  Each  time 
the  TC$AWAIT  or  TC$ADVANCE  is  invoked,  a  comparison  is  made 
between  this  Eventcount  current  value  and  the  awaited  value  to 


decide  if  the  state  of  the  process  will  remain  blocked  or 
will  be  changed  to  ready. 

The  APT$PTR  (Active  Process  Table  Pointer)  field  is 
a  pointer  which  points  to  the  first  member  of  the  blocked 
list  (the  "per  eventcount"  link  list  discussed  in  previous 
paragraph)  corresponding  to  this  specific  eventcount.  The 
usefulness  of  this  pointer  will  be  better  understood  in  the 
example  promised  in  previous  paragraph. 

This  structure  also  uses  the  variable  EVENTS  with 
initial  value  zero.  The  value  of  EVENTS  is  incremented  by 
one  each  time  the  TC$CREATE$EVC  (Traffic  Controller  Create 
Eventcount)  is  invoked  by  an  application  process.  In  this 
way  the  operating  system  keeps  track  how  many  events  are 
currently  in  use  for  inter-process  synchronization  and 
communication . 

4 .  Inner  Traffic  Controller  Eventcount  Table  (ITC$EVC$TBL) 

This  is  a  global  data  base  for  the  ITC  level  shown 
in  Figure  43  and  is  used  by  the  inter-virtual  processor 
synchronization  mechanism. 

This  table  is  a  parallel  structure  with  the  previously 
described  EVC$TABLE.  The  differences  are:  the  EVC$NAME 
in  this  table  is  not  a  character  array  but  just  a  number  (0 
to  FFH) .  The  reason  is  that  this  structure  is  invisible  for 
the  user  and  therefore  it  is  not  necessary  to  spend  execution 
time  to  improve  the  "user  interface"  (viz.,  takes  more  time 
when  we  search  the  EVC$TABLE  to  find  an  eventcount  name 
consisted  of  six  characters) . 
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ITC  EVC 

TBL 

INDEX 

EVC 

NAME 

EVC 

VALUE 

ITC$EVC$TBL  (0) 

ITC$EVC$TBL  (1) 

0 

1 

; 

_ i _ 

ITC$EVC$TBL  (2) 

2 

TABLE  43.  ITC$EVC$TBL  (INNER  TRAFFIC  CONTROLLER  EVENTCOUNT 
TABLE) 

This  structure  also  uses  the  variable  ITC$EVENTS 
(Inner  Traffic  Controller  Events)  to  keep  track  of  how  many 
events  are  currently  in  use  in  the  ITC  level,  for  inter- 
virtual  processor  communication  and  synchronization. 

5 .  System  Configuration  Data  Segment  (SCDS) 

This  is  also  a  shared  (global)  segment  containing 
the  following  information: 

NR$RPS  (Number  of  Real  Processors)  provides  the 
information  how  many  physical  processors  are  currently  used 
in  the  system. 

NR$VFS  (Number  of  Virtual  Processors)  provides  the 
number  of  virtual  processors  used  in  the  system.  It  is 
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noted  that  NR$VPS  =  NR$RPS  *  VPS$PER$CPU,  e.g.,  the  number 
of  virtual  processors  always  equals  to  the  number  of  real 
processors  multiplied  by  the  number  of  virtual  processors 
per  real  processor,  that  is  4  in  the  current  implementation. 

The  array  HDW$INT$FLAG (n)  (Hardware  Interrupt  Flag), 
is  used  by  the  hardware  interrupt  mechanism  for  directing  an 
interrupt  to  a  specific  physical  processor.  Initially  all 
the  members  of  this  array  are  set  to  zero.  The  number  of 
these  members  is  equal  to  NR$RPS  (n  =  NR$RPS  -  1) .  There  is 
one-to-one  mapping  among  HDW$INT$FLAG  and  CPU$NUMBER  (or 
LOG$CPU$NUMBER) ,  e.g.,  HDW$INT$FLAG (m)  corresponds  to 
CPU$NUMBER  =  m.  The  usefulness  of  these  flags  has  already 
been  discussed  in  paragraph  G  of  this  chapter. 

The  array  LOAD$LIST(n)  (Load  List),  is  used  in  the 
implementation  of  the  linked  list  of  the  processes  loaded  to 
each  physical  processor  (The  "Load  List"  discussed  in  the 
previous  paragraph  2,  above  APT) .  Initially  all  the  members 
of  this  array  are  set  to  zero.  The  number  of  these  members 
is  again  equal  to  NR$RPS  (n  =  NR$RPS  -1).  There  is  also  one- 
to-one  mapping  among  LOAD$LIST  and  CPU$NUMBER.  LOAD$LIST(m) 
points  to  the  currently  highest  priority  process  (independent 
of  whether  this  process  is  ready,  running,  or  blocked) 
loaded  on  the  physical  processor  with  CPU$NUMBER  (or 
LOG$CPU$NUMBER)  »  m. 
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6 .  An  Example  for  Loaded  Lists  and  Blocked  Lists 

It  is  now  feasible  to  present  an  example  to  illustrate 
the  interactions  among  LOAD $ THREAD ,  THREAD,  APT$PTR,  and 
LOAD$LIST. 

It  is  noted  that  it  is  important  for  the  reader  to 
understand  the  following  example  before  proceeding  into  the 
details  of  the  following  paragraphs  I  (about  the  Inner 
Traffic  Controller)  and  especially  K  (about  the  Traffic 
Controller) . 

Figure  44  illustrates  the  interactions  for  this 
example.  The  APT,  SCDS,  and  EVC$TABLE  tables  of  Figure  44 
do  not  show  all  their  members  but  only  the  ones  needed  to 
demonstrate  the  ideas.  It  is  supposed  that  11  processes 
corresponding  to  APT{0)  through  APT (10)  entries  of  the  APT 
have  been  loaded  on  three  different  physical  processors  with 
AFFINITY  (CPU$NUMBER  or  LOG$CPU$NUMBER)  0,  1  and  2. 

Three  linked  "Loaded  lists"  are  generated  by  the 
operating  system,  one  "per  physical  processor".  These  three 
linked  lists  are  sorted  (ordered)  by  the  priorities  of  the 
loaded  processes.  For  example,  the  L0AD$LIST(1)  of  the 
SCDS,  corresponding  to  the  physical  processor  with  AFFINITY 
=  1  (LOG$CPU$NUMBER  =  1)  points  to  the  highest  priority 
process  loaded  on  physical  processor  #1.  It  is  shown  in  the 
Figure  44,  that  LOAD$LIST(l)  =  2.  The  meaning  is  that  the 
LOAD$LIST(l)  (the  header  of  this  linked  list)  points  to  the 
entry  2  of  the  APT  (APT(2)).  In  entry  2  of  the  APT,  there 
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FIGURE  44.  LOADED  LISTS  AND  BLOCKED  LISTS 


is  loaded  a  process  on  physical  processor  #1  (AFFINITY  =  1) 
and  its  priority  is  30.  On  the  same  processor  are  loaded 
two  more  processes  corresponding  to  the  entries  5  and  9  of 
the  APT  but  their  priorities  are  lower  (66  and  40 
respectively) . 

The  LOAD$THREAD  corresponding  to  APT (2)  is  equal 
to  9.  The  meaning  is  that  the  next  process  loaded  on  this 
physical  processor  #1  is  in  the  entry  9  of  the  APT.  Indeed 
the  AFFINITY  of  APT (9)  is  also  equal  1,  and  its  LOAD$ THREAD 
field  is  equal  to  5.  The  meaning  is  that  the  next  loaded 
process  on  this  physical  processor  is  in  entry  5  of  the  APT. 
The  LOAD  $  THREAD  of  APT (5)  is  equal  to  FF  (the  NIL  pointer). 
This  means  this  is  the  last  process  (the  lowest  priority 
process)  loaded  on  physical  processor  #1.  To  summarize,  we 
have  LOAD$LIST ( 1 )  =  2  pointing  to  APT (2)  which  is  the  highest 
priority  process  (with  priority  30)  loaded  on  this  physical 
processor.  This  process  points  to  the  entry  9  (it  has 
priority  40)  and  this  second  process  in  turn  points  to  the 
entry  5  which  contains  the  third  process  (with  priority  66) 
and  its  LOAD$THREAD  =  FF  meaning  it  is  the  last  one  in  this 
linked  list. 

Similarly,  it  is  possible  now  to  easily  follow  the 
path  of  the  remaining  two  loaded  lists  (the  linked  lists  of 
the  processes  loaded  on  physical  processors  #0  and  #2) . 

It  is  also  supposed  that  several  of  these  processes 
are  in  the  blocked  state  waiting  the  cccurrence  of  some 
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event.  There  exist  three  events  in  the  EVC$TABLE  with  names 


WMEGA,  GAMMA,  and  DELTA.  The  processes  corresponding  to  the 
APT  entries  5  and  10  are  waiting  for  the  occurrence  of  the 
event  WMEGA,  the  processes  corresponding  to  the  APT  entries 
2,  4,  and  8  are  waiting  for  the  occurrence  of  the  event 
GAMMA  and  finally  the  processes  corresponding  to  the  APT 
entries  1  and  7  are  waiting  for  the  occurrence  of  the  event 
DELTA. 

Three  linked  "Blocked  lists"  are  generated  by  the 
operating  system  one  "per  eventcount".  For  example,  the 
APT$PTR  corresponding  to  the  EVC$NAME  WMEGA  is  equal  to  10. 
The  meaning  is  that  the  EVC$TABLE (0) . APT$PTR  points  to  the 
entry  10  of  the  APT  and  indeed  this  process  is  waiting  the 
occurrence  of  the  event  WMEGA.  The  THREAD  field  of  the 
APT (10)  is  equal  to  5.  The  meaning  is  that  the  process  in 
APT (5)  is  also  waiting  the  occurrence  of  the  same  event,  and 
finally  the  THREAD  field  of  APT(5)  is  equal  FF  meaning  that 
there  is  no  other  process  waiting  the  occurrence  of  the 
event  WMEGA.  It  is  noted  that  these  linked  .lists  are  per 
eventcount  and  they  link  processes  waiting  the  specific 
event  independent  of  the  processor  on  which  they  are  loaded. 

Similarly  it  is  possible  now  to  follow  easily  the 
path  of  the  remaining  two  blocked  lists  corresponding  to  the 
events  GAMMA  and  DELTA. 
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7 .  Locks  Table  (LOCKS) 

This  small  global  table  consists  only  of  the  two 
following  bytes:  APT$LOCK  and  VPM$LOCK  (Active  Process 
Table  Lock  and  Virtual  Processor  Map  Lock) .  These  two  locks 
are  used  to  prevent  race  conditions  when  accessing  the 
shared  data  bases  APT  and  VPM.  The  meaning  and  usefulness 
of  these  locks  have  already  been  discussed. 

8 .  Processor  Data  Segments  (PRDS) 

This  segment  doesn't  contain  system-wide  (global) 
data  but  "local"  data,  viz.,  data  used  for  the  specific 
microcomputer  on  which  this  segment  is  loaded.  There  exist 
a  PRDS  "per  physical  processor".  This  segment  contains  only 
the  structure  shown  in  Figure  45. 


DECLARE  PRDS  STRUCTURE 


(CPU$NUMBER 

BYTE, 

VP  $ START 

BYTE, 

VP$END 

BYTE, 

VPS$PER$CPU 

BYTE, 

IDLE$DBR 

WORD, 

COUNTER 

WORD, 

VI RT$INT$ VECTOR 

POINTER, 

HDW$INT$ VECTOR 

POINTER) 

FIGURE  45.  PROCESSOR  DATA  SEGMENT  STRUCTURE  (PRDS  STRUCTURE) 
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The  CPU$NUMBER  (A  "unique"  identification  number  for 
the  specific  physical  processor)  field,  is  assigned  to  each 
physical  processor  during  system  initialization  and  is  equal 
to  the  LOG$CPU$NUMBER  (Logical  CPU  number)  passed  as  input 
argument  to  the  module  ITC$INIT  (Inner  Traffic  Controller 
Initialization)  which  will  be  discussed  in  paragraph  lb  of 
this  chapter.  Anderson  [19]  describes  in  his  thesis  the 
details  about  system  initialization. 

The  VP $ START  and  VP$END  fields  define  the  identifica¬ 
tion  number  of  the  first  and  last  virtual  processor  assigned 
to  the  specific  physical  processor.  For  example,  in  this 
implementation,  the  physical  processor  with  identification 
number  CPU$NUMBER  =  0  corresponds  to  VP$START  =  0  and 
VP $ END  »  3,  the  physical  processor  with  CPU$NUMBER  *  1 
corresponds  to  VP$START  =  4  and  VP$END  =  7,  and  so  on. 

The  VPS$PER$CPU  (Virtual  processors  per  CPU)  field, 
determines  the  number  of  virtual  processors  assigned  to  each 
physical  processor.  In  the  current  implementation  this  number 
is  fixed  and  equal  to  4. 

The  IDLESDBR  (Address  space  descriptor  for  the  idle 
process)  field  determines  the  address  of  the  base  of  the  Idle 
Stack  (IDLES STACK)  which  is  used  by  the  Idle  Process.  Details 
about  this  stack  will  be  discussed  in  the  ITC$INIT  module  in 
paragraph  lb  of  this  chapter. 

The  COUNTER  field  is  a  software  counter.  By  contain¬ 
ing  this  member  in  the  PRDS  structure,  which  is  local  to  each 
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microcomputer  an  array  of  software  counters  is  automatically 
generated  with  one-to-one  correspondance  to  the  physical 
processors.  These  counters  are  initialized  to  zero,  and 
will  be  used  to  monitor  the  system's  performance  and  the 
effectiveness  of  the  partitioning  of  the  application  programs. 
Details  will  be  discussed  in  paragraph  Jb  of  this  chapter. 
VIRT$INT$VECTOR  and  HDW$INT$ VECTOR  (Virtual  interrupt  vector 
and  hardware  interrupt  vector)  fields  determine  the  address 
where  the  CPU  of  the  specific  microcomputer  has  to  transfer 
the  program  control  when  it  receives  a  virtual  or  a  hardware 
interrupt.  When  a  CPU  receives  a  virtual  interrupt,  it 
transfers  program  control  to  the  Traffic  Controller  Preemp¬ 
tion  Handler  (TC$PE$HANDLER) .  This  module  will  be  described 
in  the  paragraph  K,  later  on  in  this  chapter.  When  a  CPU 
receives  a  hardware  interrupt,  it  transfers  the  program 
control  to  the  hardware  interrupt  handler  of  the  Inner 
Traffic  Controller  Scheduler  (VPSCHEDULER) .  This  module 


will  be  discussed  in  the  paragraph  la,  later  on,  in  this 
chapter. 


Sequencer  Table  (SEQ$TABLE) 


This  is  a  global  data  base  for  the  TC  level  shown  in 


Figure  46  and  is  used  by  the  inter-process  synchronization 


mechanism. 


The  SEQ$TABLE  INDEX  starts  from  zero  and  grows  as 
new  sequencers  are  added  to  the  system  by  the  application 
processes.  For  example,  SEQ$TABLE(0)  represents  the  first 
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entry  (horizontal  line)  in  the  SEQ$TABLE,  SEQ$TABLE (1)  the 
second  and  so  on. 


SEQ$TABLE  (0) 


SEQ5TABLE  (1) 


SEQ$TABLE  (2) 


SEQ 

TABLE 

INDEX 

— 

SEQ 

NAME 

SEQ 

VALUE 

0 

1 

2 

< 

t 

FIGURE  46.  SEQ$TABLE  (SEQUENCER  TABLE) 


The  SEQ$NAME  (Sequencer  name)  field  is  a  character 
array  of  six  letters.  The  first  five  letters  is  the  name 
given  to  the  specific  sequencer  by  the  user  and  the  last 
letter  is  a  delimiter  (%  is  used) .  This  name  is  used  as  the 
input  argument  of  the  TC$TICKET  (Traffic  Controller  TICKET) 
operation. 

The  SEQ$VALUE  (Sequencer  value)  field  holds  the 
current  value  of  the  sequencer.  Each  time  a  TC$TICKET  opera¬ 
tion  is  executed  on  the  specific  sequencer  this  value  is  incre¬ 
mented  by  one. 
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This  structure  also  uses  the  variable  SEQUENCERS  with 
an  initial  value  of  zero.  The  value  of  SEQUENCERS  is  incre¬ 
mented  by  one  each  time  the  TC  $  CREATE  $  SEQ  (Traffic  Controller 
Create  Sequencer)  is  invoked  by  an  application  process.  In 
this  way  the  operating  system  keeps  track  of  how  many  sequencers 
are  currently  in  use  for  inter-process  communication  and 
synchronization . 

I.  THE  INNER  TRAFFIC  CONTROLLER 

The  Inner  Traffic  Controller  comprises  the  lower  level  of 
processor  multiplexing  (Level  1  of  this  virtual  machine) .  It 
multiplexes  physical  processors  among  a  fixed  set  (four  in  the 
current  implementation)  of  virtual  processors.  It  provides 
inter-virtual  processor  communication  and  synchronization, 
supports  the  management  of  physical  resources  and  manages  the 
system's  interrupt  structure. 

The  Inner  Traffic  Controller  creates  a  set  of  four  virtual 
processors  with  the  following  extended  instruction  set: 
ITC$AWAIT,  ITC$ADVANCE ,  ITC$LOAD$VP,  IDLE$VP,  ITC$SEND$PREEMPT , 
and  ITC$RET$VP.  It  also  contains  the  internal  routines 
HARDWARE  $ INT ,  LOCKVPM,  UNLOCKVPM,  CHECK$PREEMPT ,  RDYTHISVP  and 
SWAPDBR. 

ITC$ AWAIT  and  ITC$ADVANCE  (Inner  Traffic  Controller  AWAIT 
and  ADVANCE)  provide  an  inter-virtual  processor  synchronization 
mechanism  used  within  the  kernel  to  provide  multiprogramming. 
This  multiprogramming  is  realized  by  invoking  the  scheduling 
procedure  GETWORK,  of  the  ITC,  which  multiplexes  these  four 
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virtual  processors  on  a  physical  processor.  Which  VP  will 
finally  run  on  the  physical  processor  is  decided  by  the 
VPSCHEDULER  (Inner  Traffic  Controller  Scheduler) . 

ITC$LOAD$VP  (Inner  Traffic  Controller  Load  Virtual  Pro¬ 
cessor)  performs  the  "binding"  of  a  new  process  to  a  virtual 
processor.  It  is  called  by  the  TC$SCHEDULER  (Traffic  Control¬ 
ler  Scheduler)  when  a  process  has  been  selected  for  the  VP. 

IDLE$VP  (Idle  this  VP)  is  the  ITC$LOAD$VP ' s  counterpart. 

It  is  called  by  the  TC$SCHEDULER  in  case  that  there  exist  no 
runnable  process  for  the  VP.  The  virtual  processor  will  be 
idled  (enter  the  "idle  state"). 

CHECKS PREEMPT  and  ITC$SEND$PREEMPT  (Check  for  Pending 
Preempt  Interrupt  and  ITC  Send  Preempt  Interrupt)  create  a 
virtual  processor  interrupt  mechanism.  CHECK$PREEMPT ,  when 
it  is  invoked  within  the  ITC,  checks  the  PE$PEND  (Preemption 
Pending  Flag)  field  of  the  VPM  to  determine  if  it  is  set  or 
reset  for  the  specific  VP.  ITC$SEND$PREEMPT  is  invoked  from 
level  2  ( TC S ADVANCE )  when  the  Traffic  Controller  desires  to 
load  a  new  process  on  a  virtual  processor  that  is  not 
scheduled. 

ITC$RET$VP  (Inner  Traffic  Controller  Return  Virtual  Pro¬ 
cessor’s  identification  number),  when  it  is  invoked,  provides 
the  information  which  VP  is  currently  scheduled  (running)  on 
the  physical  processor.  This  identity  is  only  valid  so  long 
as  the  APT  is  locked.  The  identity  of  a  particular  VP  must 
be  known  in  the  virtual  environment,  just  as  the  identity  of 
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a  physical  processor  is  required  to  be  known  in  the  multi¬ 
processor  system. 

HARDWARE? INT  (hardware  interrupt)  is  used  within  the  ITC 
to  send  a  hardware  interrupt  from  one  physical  processor 
to  another.  The  purpose  is  to  support  preemptive  scheduling 
needed  in  the  real-time  processing. 

LOCKVPM  and  UNLOCKVPM  (Lock  and  Unlock  the  Virtual  pro¬ 
cessor  map)  are  used  to  set  or  reset  a  software  lock  on  the 
shared  (global)  VPM  data  base  to  assure  there  are  no  race 
conditions . 

RDYTHISVP  (Ready  this  VP)  is  used  to  change  the  state  of 
the  currently  "running"  VP  to  "ready". 

SWAPDBR  (Swap  DBR)  is  a  function  within  the  Inner 
Traffic  Controller  Scheduler  and  is  used  to  change  the 
address  space  when  a  new  process  is  scheduled  to  run  when 
the  previous  process  has  been  completed  or  blocked. 

The  details  of  the  Inner  Traffic  Controller  modules  will 
be  discussed  below: 

1 .  Virtual  Processor  Scheduler  (VPSCHEDULER) 

This  module  is  responsible  for  making  the  scheduling 
decisions  for  virtual  processors.  It  selects  the  highest 
priority  virtual  processor  from  the  set  of  four  virtual 
processors  assigned  to  the  physical  processor  and  schedules 
it.  There  are  two  distinct  entry  points  to  the  VPSCHEDULER, 
the  normal  entry  and  the  interrupt  entry. 


The  normal  entry  point  is  used  by  other  Inner 


Traffic  Controller  modules  to  activate  VPSCHEDULER  when  a 
virtual  processor  gives  up  the  physical  processor  on  its 
own.  The  preempt  interrupt  entry  point  is  used  in  response 
to  a  hardware  preempt  interrupt  from  another  physical 
processor. 

VPSCHEDULER  next  searches  through  the  fixed  set  of 
virtual  processors  for  the  highest  priority  "eligible" 
virtual  processor.  In  this  implementation  the  definition  of 
eligible  includes  not  only  a  ready  VP  but  also  the  combina¬ 
tion  of  an  idle  state  and  a  pending  virtual  preempt  interrupt. 
This  allows  an  idle  virtual  processor  to  run  so  that  it  may 
field  the  interrupt  and  bind  itself  to  a  new  process.  The 
idle  process  that  was  bound  to  the  virtual  processor  was 
essentially  useless  up  to  this  point.  It  now  provides  an 
address  space  in  which  the  virtual  processor  can  execute 
when  binding  to  a  new  process. 

Having  selected  some  eligible  virtual  processor,  the 
VPSCHEDULER  proceeds  to  bind  the  selected  virtual  processor 
to  the  physical  processor.  I *■  er  »  by  unbinding  the 
currently  running  virtual  processor.  In  doing  so,  the  Stack 
Pointer  Register  (SP)  value,  and  the  Base  Pointer  Register 
(BP)  value  are  saved  in  known  locations  on  the  process' 
stack.  The  process'  execution  state  (point)  had  already 
been  saved. 
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Binding  the  selected  virtual  processor  is  begun  by 
changing  the  Stack  Segment  (SS)  Register  value  to  that  of 
the  selected  virtual  processor.  Once  this  change  has  been 
made,  execution  has  actually  swapped  to  the  new  process 
address  space.  Binding  is  completed  by  retrieving  the 
previously  saved  stack  Pointer  Register  value  and  the  Base 
Pointer  Register  value  from  the  newly  acquired  stack. 

The  last  step  is  to  actually  return  to  the  proper 
place  in  the  VPSCHEDULER.  If  a  preempt  interrupt  invoked 
VPSCHEDULER,  an  interrupt  return  will  be  executed  and 
CHECKPREEMPT  will  see  if  a  virtual  preempt  interrupt  is 
pending.  If  a  preempt  interrupt  is  found  to  be  pending,  the 
program  control  will  be  transferred  to  the  location  specified 
by  PRDS.VIRT$INT$VECT0R  (viz.,  to  the  Traffic  Controller's 
preempt  handler) . 

There  is  one  other  internal  module  for  the  Virtual 
Processor  Scheduler,  the  hardware  interrupt  handler.  It  is 
used  to  handle  hardware  preempt  interrupts.  The  program 
control  is  transferred  in  this  module  each  time  the  HARD- 
WARE$INT  module  of  the  ITC  is  invoked.  Details  about  the 
hardware  preempt  interrupt  mechanism  have  already  been 
discussed  in  the  paragraph  G  of  this  Chapter.  (For  the 
algorithm  see  Figure  38) . 

2 .  ITC$INIT  (Inner  Traffic  Controller  Initialization) 

This  module  together  with  the  following  KERNEL$INIT 
perform  part  of  the  system  initialization  by  initializing  the 
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stack  of  the  Idle  Process  and  also  the  stack  of  the  Memory 
Management  Process.  These  two  system  processes  run  concept¬ 
ually  between  the  TC  and  ITC  levels  as  shown  in  Figures  5  and 
9.  These  two  processes  are  scheduled  by  the  VPSCHEDULER 
(the  ITC  scheduler) ,  and  are  "invisible"  to  the  TC$SCHEDULER 
(generally  to  the  TC  level) .  That  means  there  is  no  entry 
into  the  APT  (Active  Process  Table)  for  these  two  processes. 
Also  the  stack  initialization  for  these  processes  is  differ¬ 
ent  from  the  corresponding  initialization  of  an  application 
process  stack.  Details  about  these  two  system  processes 
will  be  discussed  after  the  completion  of  the  ITC  level. 

This  module  just  calls  the  KERNEL$INIT  module  and 
then  calls  the  VPSCHEDULER  that  schedules  the  highest  priority 
virtual  processor  (VP  #0)  to  run.  VP  #0  is  permanently  bound 
to  the  Memory  Management  Process. 

ITC$INIT  accepts  two  input  arguments,  CPU$NUMBER  (that 
is  equal  to  the  LOG$CPU$NUMBER,  logical  CPU  number)  and 
PHYS$CPU$NUMBER  (physical  CPU  number) .  These  two  arguments 
LOG$CPU$NUMBER  and  PHYS$CPU$NUMBER  are  given  values  during 
the  system  initialization  [19] . 

ITC$INIT  is  the  entry  point  for  the  distributed  oper¬ 
ating  system. 

3 .  KERNBL$INIT  (Kernel  Initialization) 

This  module  is  called  only  by  the  ITC$INIT  and  is 
executed  by  each  processor  once  during  the  system 
initialization.  It  declares  the  IDLE$STACK  and  MGMT$ STACK 
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(Idle  Process  Stack  and  Memory  Management  Stack  respectively) 
as  based  structures,  it  then  initializes  these  two  stacks  by 
initializing  the  header  of  the  stack  and  the  register's 
array  and  then  initializing  the  maximum  stack  length,  and 
the  process'  initial  code  segment  (CS)  register,  instruction 
pointer  (IP)  register  and  the  flags.  (See  Figure  22). 

Then  the  program  control  returns  into  ITC$INIT 

module . 

4.  GET$COUNTER  (Get  Current  Value  of  COUNTER) 

This  is  just  a  "utility  function"  called  only  by  the 
Idle  Process.  It  gets  the  current  value  of  the  counter 
(which  is  a  member  of  the  PRDS,  (see  Figure  45))  and  returns 
that  value  to  the  Idle  Process. 

5 .  UPDATE$COUNTER  (Upd  te  the  Value  of  counter) 

This  is  also  a  "utility  function"  called  only  by  the 
Idle  Process  and  has  the  purpose  to  update  (increment  by 
one)  the  current  value  of  the  COUNTER.  The  usefulness  of 
these  two  utility  functions  will  be  discussed  when  describ¬ 
ing  the  Idle  Process. 

6.  GET$CURRENT$DBR  (Get  Current  DBR) 

This  is  also  a  "utility  function"  and  is  called  only 
by  the  VPSCHEDULER.  When  making  an  implicit  call  to  the 
ITC$RET$VP  (discussed  below) ,  it  finds  the  identity  (VP 
number)  of  the  currently  running  virtual  processor  and  then 
finds  and  returns  the  content  of  the  Stack  Segment  (SS) 
register,  corresponding  to  the  specific  running  VP.  Recall 


that  the  SS  register  is  used  in  this  design  in  a  manner 
analogous  to  the  DBR  in  the  MULTICS  system.  This  D3R 
value  is  used  by  the  VPSCHEDULER  to  identify  the  right 
address  space  and  continue  execution  after  receiving  a 
hardware  interrupt. 

We  note  here  that  each  time  a  module  returns  a  func¬ 
tion  value,  this  value  in  PL/M-86  always  goes  into  the 
accumulator  (AX)  register. 

7 .  ITC$RET?VP  (Inner  Traffic  Controller  Return  VP  Number) 
This  is  also  a  "utility  function"  used  by  the  Inner 
Traffic  Controller  and  Traffic  Controller  modules.  ITC$RET$VP 
searches  the  Virtual  Processor  Map  and  determines  the  identity 
of  the  virtual  processor  that  is  currently  running  on  the 
physical  processor.  It  simply  checks  for  the  virtual 
processor  among  the  virtual  processors  assigned  to  the 
physical  processor  which  is  in  the  running  state.  ITC$RET$VP 
then  returns  its  result  as  a  function  value  into  the  AX 
(accumulator)  register.  It  will  return  either  the  identity 
of  the  virtual  processor  (the  virtual  processor’s  index  in 
the  Virtual  Processor  Map)  or  a  "not  found"  error  code. 

8 •  ITC$RET$VPTC  (ITC  Return  VP  number  for  TC) 

It  is  a  "utility  function"  which  is  used  to  perform 
the  VP  mapping  between  the  TC  and  ITC  levels  as  already 
mentioned  in  paragraphs  HI  and  H2  (about  VP$ID  Field)  of 
this  Chapter. 
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All  the  four  VP’s  in  the  Figure  39  are  visible  to 
the  ITC.  The  two  central  VP's  are  visible  to  the  TC  while 
VP  $  START  and  VP$END  are  invisible.  The  user  processes  are 
multiplexed  among  these  two  central  VP's  of  each  physical 
processor. 

The  ITC$RET$VPTC  when  called  by  the  TC,  it  calls  in 
turn  the  ITC$RET$VP  to  obtain  the  currently  running  VP  (its 
index  in  VPM) .  It  then  performs  the  mapping  shown  in  Figure 
47,  and  finally  returns  the  corresponding  VP  identification 
number  for  the  TC  (VP$ID  in  Figure  47) . 

9 .  ITC$LOAD$VP  (Inner  Traffic  Controller  Load  Virtual 

Processor) 

This  module  performs  the  "binding"  of  a  new  process 
to  a  virtual  processor.  It  is  called  by  the  Traffic  Controller 
Scheduler  (TC$3CHED(JLER)  when  a  process  has  been  selected  for 
the  virtual  processor.  LOAD$VP  requires  two  input  parameters, 
the  priority  of  the  new  process  and  the  address  space  descriptor 
(the  Stack  Segment  Register  value) .  It  then  swaps  in  the  new 
process  onto  the  virtual  processor  which  is  currently  running. 
ITC$LOAD$VP  only  operates  on  the  virtual  processor  which  is 
running  on  the  physical  processor. 

Binding  is  accomplished  by  updating  the  Virtual  Pro¬ 
cessor  Map.  The  Inner  Traffic  Controller  utility  function 
ITC$RET$VP  is  used  to  obtain  the  identity  of  the  running 
virtual  processor.  When  complete,  the  virtual  processor  will 
have  a  new  priority  and  process  address  space  descriptor 


178 


FIGURE  47.  VIRTUAL  PROCESSOR  MAPPING  BETWEEN  ITC  AND  TC 


(corresponding  to  the  priority  and  address  space  of  the  pro¬ 
cess  just  bound  to  it) .  ITC$LOAD$VP  completes  by  calling 
VPSCHEDULER  to  reschedule  the  virtual  processor. 

10 .  IDLE$VP  (Idle  this  Virtual  Processor) 

This  function  is  ITC$LOAD$VP 1 s  counterpart.  It  is 
called  by  the  TC$SCHEDULER  (Traffic  Controller  Scheduler)  in 
the  event  that  a  runnable  process  is  not  found  for  the  virtual 
processor.  In  this  case  the  virtual  processor  will  be  idled 
(enter  the  idle  state)  and  the  Idle  Process  will  be  bound  to 
it.  In  the  Virtual  Processor  Map,  the  virtual  processor's 
state  will  be  marked  as  idle,  the  address  space  descriptor 
for  the  Idle  Process  will  be  entered  in  the  Address  Space  of 
Bound  Process  field.  The  idle  state  ensures  that  the  idle 
process  is  not  actually  run  by  taking  the  virtual  processor 
entirely  out  of  contention  for  the  physical  processor,  with 
which  this  virtual  processor  is  associated. 

At  some  later  point,  the  virtual  processor  may  be 
placed  back  in  "contention"  for  resources.  This  will  occur 
when  the  virtual  processor  is  "preempted".  With  the  combina¬ 
tion  of  an  "idle  state"  and  a  "pending  preempt",  the  virtual 
processor  is  treated  the  same  way  as  a  "ready"  virtual  proces¬ 
sor  (We  shall  clarify  that  statement  when  describing  the 
GETWORK  module) .  This  allows  the  virtual  processor  to  keep 
busy  by  expediting  its  binding  to  a  process. 

Lastly  IDLE$VP  calls  VP$SCHEDULER  in  order  to  "give 
up"  the  physical  processor. 
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11 .  CHECK? PREEMPT  (Check  for  Pending  Preempt  Interrupt) 

This  module  is  called  by  the  VPSCHEDULER  during  the 

execution  of  a  "virtual  interrupt  return" .  It  checks  for  a 
pending  preempt  interrupt  meant  for  the  virtual  processor, 
which  has  been  selected  to  run  (the  running  VP)  by  the 
VPSCHEDULER.  To  accomplish  this  it  checks  the  virtual 
processor's  "preempt  pending  flag"  (PE$PEND)  in  the  VPM 
(Virtual  Processor  Map) .  If  the  preempt  pending  flag  is  set, 
the  CHECK? PREEMPT  will  reset  it  and  return  the  found  value 
(flag  "on"  or  "down")  to  the  VPSCHEDULER.  In  this  way  the 
VPSCHEDULER  is  informed  about  the  state  of  PE?PEND  flag  and 
it  will  use  this  information  to  decide  which  VP  will  run 
(see  GETWORK  module  below) . 

12.  GETWORK 

It  is  a  function  call.  Initially  it  sets  its  local 
variable  PRI  (Priority)  equal  to  the  lowest  possible  priority. 
(In  this  implementation,  the  lowest  priority  is  255  and  the 
highest  is  0)  and  SELECTED?DBR  (selected  address  space) 
equal  to  IDLE?DBR  (the  address  space  for  the  idle  process) . 

It  then  searches  the  VPM  (Virtual  Processor  Map)  to 
find  the  highest  priority,  "eligible"  to  run,  virtual  processor. 
In  this  implementation  eligible  to  run  for  a  virtual  processor 
means  it  is  either  in  the  "ready"  state,  or  the  "idle"  state 
with  a  "virtual  preempt  pending"  (PE?PEND  is  set) . 

Using  the  above  criterion,  GETWORK  selects  an  eligible 
processor,  sets  the  SELECTED$DBR  and  PRI  equal  to  the 
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corresponding  VPM  values  SS$REG  and  VP$PRIORITY  respectively 
for  the  selected  VP,  and  then  sets  its  state  to  "running" 
and  finally  returns  the  SELECTED$DBR  into  the  Accumulator. 

If  after  the  above  search  no  eligible  VP  is  found, 
it  defaults  SELECTED$DBR  =  IDLE$DBR  and  the  idle  process 
will  run. 

13 .  ITC$SEND$PREEMPT  (Inner  Traffic  Controller  Send 
Preempt  Interrupt) 

This  module  is  responsible  for  actually  sending  pre¬ 
empt  interrupts.  It  is  called  by  the  Traffic  Controller 
Advance  module.  ITC$SEND$PREEMPT  requires  two  arguments,  the 
identity  of  the  virtual  processor  which  is  to  be  preempted 
and  the  identity  of  the  physical  processor  to  which  that 
virtual  processor  is  associated. 

It  first  locks  the  VPM  (Virtual  Processor  Map)  and 
then  sets  the  virtual  processor's  PE$PEND  (Preempt  Pending 
Flag) .  This  is  all  that  is  done  when  the  virtual  processor 
to  be  preempted  is  associated  to  the  physical  processor,  which 
is  the  transmitter  (executing  the  ITC$SEND$PREEMPT  module) . 

In  other  words,  when  the  TGT$CPU  (the  input  argument  showing 
the  identity  of  the  physical  processor  possessing  the 
virtual  processor  for  which  the  virtual  preempt  interrupt  is 
destined)  is  equal  to  the  CPU$NUMBER  (the  identity  of  the 
physical  processor  executing  ITC$SEND$ PREEMPT) . 

Otherwise,  after  setting  the  PE$PEND  the  ITC$SEND$- 
PREEMPT  calls  the  HARDWARE$INT  procedure  (see  next  paragraph) 
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to  generate  a  hardware  interrupt  for  the  physical  processor 
possessing  the  virtual  processor  to  be  preempted. 

Finally  the  ITC$SEND$PREEMPT  unlocks  the  VPM  and 
returns  to  the  TC$ADVANCE  (the  module  responsible  for  pre¬ 
emptive  scheduling) . 

14.  HARDWARE  $ INT  (Hardware  Interrupt) 

This  procedure  requires  as  its  input  argument  the  CPU$- 
NUMBER,  viz.,  the  identity  of  the  physical  processor  for  which 
the  hardware  interrupt  is  destined.  HARDWARE  $ INT  procedure 
first  sets  the  "global"  hardware  interrupt  flag  corresponding 
to  this  physical  processor  (HDW$INT$FLAG (CPU) ) .  It  then 
sends  a  hardware  interrupt  by  outputting  in  the  parallel 
PORT  "C" ,  first  a  "0"  then  an  "80H”  and  again  a  "0”. 

Finally  the  program  control  returns  to  the  calling  procedure. 
The  details  about  this  hardware  preempt  interrupt  already 
have  been  discussed  in  paragraph  G  of  this  chapter.  HARD¬ 
WARES  I  NT  is  called  only  by  the  ITC$SEND$PREEMPT  and 
ITC$ ADVANCE  modules. 

15 .  LOCKVPM  (Lock  Virtual  Processor  Map) 

This  small  module  uses  a  built-in  PL/M-86  procedure 
called  LOCKSET  which  is  an  "indivisible  test-and-set  semap¬ 
hore"  to  implement  a  software  lock  called  L0CK$VPM  in  the 
VPM  which  is  the  central  shared  data  base  in  the  Inner 
Traffic  Controller  Level  (see  Figure  9) .  Because  this 
global  data  base  can  be  accessed  (read  and  write  capability) 
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by  all  the  virtual  processors,  this  lock  is  used  to  prevent 
"race  conditions". 

16.  UNLOCKVPM  (Unlock  Virtual  Processor  Map) 

This  module  is  the  counterpart  of  the  above  LOCKVPM. 
Each  time  we  have  to  access  the  VPM,  we  first  lock  the 
VPM$LOCK.  When  the  access  task  is  finished,  we  have  to 
unlock  this  VPM$LOCK,  so  that  another  virtual  processor  can 
access  it. 

17 .  RDYTHISVP  (Ready  this  Virtual  Processor) 

This  module  first  finds  which  Virtual  Processor  is 
currently  running  by  calling  implicitly  ITC$RET$VP  and  then 
changes  the  state  of  this  VP  from  "running"  to  "ready". 

18 .  ITC$ LOCATE $EVC  (Inner  Traffic  Controller  Locate 
Eventcount) 

This  is  a  utility  function.  It  returns  the  index  of  an 
ITC  Eventcount  in  the  ITC  Eventcount  Table  (ITC$EVC$TBL) .  It 
is  called  only  by  ITC$AWAIT  and  ITC $ ADVANCE  described  below. 

The  input  argument  is  the  name  of  this  ITC  Eventcount.  ITC$- 
LOCATES EVCJ  attempts  to  match  the  name  given  to  it  with  one  in 
the  ITC$EVC$TBL .  If  a  match  is  found,  it  returns  the  index 
to  the  calling  procedure  in  the  AX  (Accumulator)  Register  as 
a  function  value.  Otherwise,  it  returns  an  error  code. 

19.  ITCSAWAIT  (Inner  Traffic  Controller  AWAIT) 

ITCSAWAIT  is  an  inter-virtual  processor  synchroniza¬ 
tion  primitive.  It  is  "invisible"  (not  accessible)  to  the 
user  processes  and  is  used  only  by  the  operating  system  in 
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the  management  of  physical  resources.  It  allows  a  virtual 
processor  to  wait  for  the  occurrence  of  an  ITC  Eventcount. 

ITC$ AWAIT  expects  two  input  arguments,  the  name  of 
the  Eventcount  and  the  value  of  the  event  to  be  awaited. 

Upon  invokation  ITC$AWAIT  locks  the  VPM.  It  then 
finds  first  which  Virtual  Processor  is  running  by  making  an 
implicit  call  to  the  ITC$RET$VP  and  then  finds  the  index  of 
the  Eventcount  in  the  ITC$EVC$TBL  by  making  an  implicit  call 
to  the  ITC$LOCATE$EVC .  It  then  compares  the  current  value 
of  the  Eventcount,  obtained  from  the  ITC$EVC$TBL  with  the 
value  passed  in  the  call.  If  the  current  value  of  the 
Eventcount  is  found  to  be  less  than  the  value  of  the  input 
argument,  then  the  virtual  processor  will  enter  the  "waiting 
state  and  "gives  up"  the  physical  processor. 

This  change  of  the  virtual  processor's  state  from 
"running"  to  "waiting"  will  be  reflected  in  the  VPM.  The 
input  arguments  will  also  be  entered  in  the  VPM  in  the 
EVC$AW$ID  (Identity  of  the  Awaited  Eventcount)  and  the 
EVC$AW$ VALUE  (Eventcount  Awaited  Value)  fields. 

Otherwise,  if  the  current  value  of  the  Eventcount  is 
found  to  be  equal  or  greater  than  the  value  of  the  input 
argument,  then  the  state  of  this  virtual  processor  will  be 
changed  from  "running"  to  "ready". 

Finally,  in  both  cases  the  virtual  processor  will 
give  up  the  physical  processor  by  calling  the  VPSCHEDULER , 
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which  will  bind  another  (or  possibly  the  same^)  virtual 
processor  to  this  physical  processor.  Upon  the  return  from 
the  VPSCHEDULER,  the  VPM  will  be  unlocked. 

20.  I TC$ ADVANCE  (Inner  Traffic  Controller  ADVANCE) 

I TC$ ADVANCE  is  an  inter-virtual  processor  synchroniza¬ 
tion  primitive.  It  also  is  "invisible"  to  the  user  processes 
and  is  used  only  by  the  operating  system  in  the  management  of 
the  physical  resources.  It  expects  one  input  argument,  the 
name  of  the  ITC  Eventcount  to  be  advanced. 

Upon  invocation,  the  VPM  is  locked.  I TC $ AD VAN CE  then 
finds  which  VP  is  running  by  making  an  implicit  call  to  the 
ITC$RET$VP  to  change  the  state  of  this  VP  from  "running"  to 
"ready".  It  then  finds  the  index  of  the  Eventcount  in  the 
ITC$EVC$TBL  by  making  an  implicit  call  to  the  I TC $ LOCATE $EVC, 
and  the  eventcount' s  value  in  this  table  is  incremented  by 
one. 

ITC  $ ADVANCE  then  compares  this  incremented  value  with 
the  events  waited  for  by  the  other  virtual  processors  which 
are  synchronizing  on  the  same  eventcount.  All  those  virtual 
processors  whose  Eventcount  Awaited  Value  field  (EVC$AW$ VALUE) 
in  the  VPM  is  less  than  or  equal  to  the  current  value  of  the 
eventcount  are  set  to  the  "ready"  state.  This  is  the  "broad¬ 
cast  effect"  discussed  in  paragraph  F5e3  of  this  chapter. 

^Will  be  the  same  only  in  case  the  state  of  the 
VP  changed  from  "running"  to  "ready"  and  if  this  is 
the  highest  priority  ready  VP. 
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Finally,  the  ITC$ADVANCE  calls  VPSCHEDULER  to  schedule 
the  next  VP.  Upon  return  from  VPSCHEDULER,  it  will  unlock 
the  VPM . 

J.  KERNEL  PROCESSES 

The  kernel  processes  make  up  the  non-distributed  kernel. 
Non-distributed  here  has  the  meaning  that  these  processes  are 
not  distributed  as  part  of  each  process's  address  space. 
Instead  they  represent  system  services  and  are  used  in  the 
management  of  physical  resources  and  execute  asychronously 
with  respect  to  user  processes. 

In  this  implementation  all  system  processes  are  permanent¬ 
ly  bound  to  dedicated  virtual  processors,  because  it  is  very 
expensive  to  use  a  dedicated  real  processor. 

Currently,  two  kernel  processes  are  used,  the  Memory 
Management  Process  and  the  Idle  Process  (MMGT  and  IDLE  Process 
respectively) .  The  MMGT  process  controls  both  primary  and 
secondary  memory  and  the  IDLE  process  defines  the  "no  work" 
state  of  the  system. 

The  currently  implemented  MMGT  and  IDLE  processes  do  not 
have  their  final  form.  Instead  they  are  "stubs"  for  these 
processes.  The  current  implementation  does  provide  the 
interface  of  these  processes  with  the  operating  system  and  the 
inter-virtual  processor  synchronization  mechanism,  which  is 
the  most  difficult  task  when  implementing  such  processes. 

(This  inter-virtual  processor  synchronization  mechnism  will 
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also  be  used  in  the  future  when  Input/Output  management  will 
be.  added  to  the  system.) 

1 .  The  Memory  Management  Process  (MMGT  Process) 

The  currently  implemented  MMGT  process  is  permanently 
bound  to  the  VP$START  (see  Figure  39)  and  the  IDLE  process 
is  permanently  bound  to  the  VP$END.  In  this  way  these  two 
virtual  processors  are  in  contention  for  physical  processors 
but  not  for  application  (user)  process  scheduling. 

Anderson  [19]  in  his  thesis  describes  the  system- 
wide  initialization.  Below  is  described  what  is  going  on 
in  each  physical  processor. 

Each  physical  processor  starts  executing  in  the  code 
of  the  ITCSINIT  module  (see  paragraph  12  of  this  chapter) . 

This  module  ends  with  a  call  to  VPSCHEDULER .  The  VPSCHEDULER 
schedules  the  highest  priority  (i.e.,  VP$START)  virtual 
processor  to  run  on  each  physical  processor.  In  this  way 
each  physical  processor  executes  the  MMGT  process  as  its 
first  process. 

The  MMGT  process  calls  the  loader  module  which 
repeatedly  calls  the  CREATE $PROCESS  module.  When  the  loader 
is  finished,  the  number  of  APT  entries  (processes)  is  equal 
to  the  number  of  application  processes  to  be  loaded.  The 
module  CREATE$PROCESS  (see  paragraph  K10  in  this  chapter) 
initializes  the  address  space  (stacks)  for  each  process  and 
finally  calls  the  module  AWAIT$FOR$START  (see  paragraph  K8) . 
The  result  is  that  each  newly  created  process  becomes  blocked 
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waiting  for  the  special  eventcount  "START",  v/ith  initial 
value  zero,  to  reach  the  value  1. 

When  no  other  process  remains  to  be  loaded  the  MMGT 
process  invokes  ADVANCE$FOR$START.  The  result  is  that  the 
value  of  this  special  eventcount  START  reaches  the  value  1  and 
all  the  created  processes  on  its  blocked  list  (see  Figure  44) 
are  now  awakened. 

Then  the  MMGT  process  calls  the  module  ITCSAWAIT 
(see  paragraph  119  of  this  chapter) .  The  result  is  that  the 
VP $ START  enters  the  waiting  state  and  finally  the  VPSCHEDULER 
is  invoked.  The  VPSCHEDULER  will  schedule  the  VP  which  is 
loaded  with  the  highest  priority  application  process  (one  of 
the  two  central  VP  of  Figure  39)  since  the  VP$END  is  bound 
to  the  IDLE  process.  If  no  application  processes  are  loaded 
on  the  specific  physical  processor,  the  VPSCHEDULER  will 
schedule  the  lowest  priority  VP$END  to  run  the  IDLE  process, 
since  the  highest  priority  MMGT  process  is  currently  blocked. 

2 .  The  Idle  Process  (IDLE  Process) 

The  IDLE  process  defines  the  "no  work"  state  of  the 
system.  The  operating  system  attempts  to  schedule  useful 
work  on  system  processors  whenever  feasible.  If  there  is  no 
work  then  the  IDLE  process  assures  that  the  physical  processor 
always  has  some  valid  process  address  space  to  execute  in. 

The  idle  virtual  processors  act  as  "default"  processors  that 
will  only  be  run  when  no  other  eligible  VP  is  found. 
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Currently  the  IDLE  process  constitutes  just  an  "idle 
loop".  When  the  IDLE  process  is  running,  the  this  loop  is 
first  entered  the  current  value  of  the  PRDS  software  COUNTER 
(see  paragraph  H8  of  this  chapter)  is  obtained.  Afterwards 
each  time  this  idle  loop  is  executed  this  COUNTER  is  updated 
(see  also  paragraphs  14  and  15) . 

By  being  able  to  read  the  value  of  these  COUNTERS 
(one  per  physical  processor)  the  performance  of  the  operating 
system,  the  hardware  communication  links  between  different 
"clusters"  and  finally  the  effectiveness  of  the 

application  processes  "partitioning"  can  be  actually  tested. 

The  reason  is,  this  COUNTER  value  records  how  much 
time  each  real  processor  executed  in  the  IDLE  process.  These 
values  can  be  interpreted  and  used  as  relative  time  or  as 
actual  time  by  multiplying  the  COUNTER'S  value  by  the  time 
needed  this  idle  loop  to  be  executed  once. 

When  in  the  future  the  preventive  fault  diagnosis 
and  recovery  routines  are  developed,  part  of  these  routines 
will  be  incorporated  into  the  IDLE  process,  so  that  when  a 
physical  processor  has  no  work  it  will  execute  this  preventive 
fault  diagnosis  routine  instead  of  idling. 

K.  THE  TRAFFIC  CONTROLLER 

The  Traffic  Controller  resides  at  level  2,  multiplexes 
the  user  processes  among  virtual  processor  and  manages  the 
execution  of  these  processes  (process  management)  by  invoking 
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the  extended  instructions  of  the  virtual  processors  in  level 
1  (ITC-level) .  In  addition  to  implementing  the  level  2 
scheduling  algorithm,  the  Traffic  Controller  creates  the  ex¬ 
tended  instruction  set:  TC$AWAIT  and  TC$ ADVANCE . 

TC$AWAIT  and  TC$ADVANCE  (Traffic  Controller  AWAIT  and 
ADVANCE)  are  used  to  implement  an  inter-process  communica¬ 
tion  and  synchronization  mechanism  invoked  by  the  Supervisor, 
by  using  the  eventcounts  and  sequencers. 

The  Traffic  Controller's  principal  global  data  base  (APT) 
has  already  been  discussed  in  paragraph  H2  of  this  chapter. 
Each  entry  of  the  APT  corresponds  to  an  application  process 
and  contains  sufficient  information  to  enable  a  virtual  pro¬ 
cessor  to  be  bound  to  and  execute  it. 

1.  Process  Scheduler  (TC$SCHEDULER) 

The  TC$ SCHEDULER  works  in  essentially  the  same  way 
that  the  Inner  Traffic  Controller's  Scheduler  (VPSCHEDULER) 
does.  However,  the  TC$ SCHEDULER  schedules  processes,  while 
the  VPSCHEDULER  schedules  virtual  processors.  The 
TC$ SCHEDULER  can  be  called  by  the  TC$AWAIT,  TC$ ADVANCE ,  and 
TC$ PE $ HANDLER  (Traffic  Controller  Preemption  Handler) . 

It  selects  the  highest  priority  ready  process  from 
the  specific  microcomputer's  Loaded  List  (see  Figure  44)  to 
be  bound  to  an  available  virtual  processor.  The  TC$ SCHEDULER 
works  only  with  the  processes  which  are  runnable  on  its  own 
physical  processor  using  the  fixed  set  of  the  four  virtual 
processors  assigned  to  this  physical  processor. 


191 


AD-A104  071  NAVAL  POSTGRADUATE  SCHOOL  MON  I E  ML  T  CA  F/G 

DETAILED  DESIGN  AND  IMPLEMENTA1 ir  j  OF  I  HE  KERNtL  OF  A  REAL-TIME _ ETC(U) 

MAR  81  D  K  KAHANT^iKOS  MUUJ 


When  the  TC$SCHEDULER  finds  a  runnable  process,  the 


Inner  Traffic  Controller  module  ITC$LOAD$VP  is  called  to  bind 
the  selected  process  to  the  running  virtual  processor.  Alter¬ 
natively,  if  there  is  no  runnable  process,  the  virtual  pro¬ 
cessor  will  be  idled  (bound  to  the  Idle  Process  and  placed 
in  the  idle  state)  by  a  call  to  the  Inner  Traffic  Controller 
module  IDLE$VP. 

2 .  Traffic  Controller  Locate  Eventcount  (TC$LOCATE$EVC) 
This  is  a  "utility"  function  called  only  by  the 

Traffic  Controller  modules  TC$AWAIT  and  TC$ADVANCE.  Together 
with  the  following  module  TC$LOCATE$SEQ  it  is  used  to  simplify 
the  handling  of  eventcounts  and  sequencers  respectively. 

Its  input  argument  is  a  pointer  to  the  name  of  the 
eventcount.  When  invoked,  TC$LOCATE$EVC  makes  a  linear 
search  in  the  Eventcount  table  (EVC$TABLE)  to  locate  the 
desired  eventcount  by  matching  the  names.  If  a  match  is 
found  it  returns  the  index  of  the  specific  eventcount  in  the 
EVC$ TABLE  in  the  Accumulator  (AX)  register,  otherwise  (if 
not  found) ,  it  returns  an  error  code. 

3 .  Traffic  Controller  Locate  Sequencer  (TC$LOCATE$SEQ) 
This  is  the  second  "utility"  function  used  in  the 

handling  of  sequencers  and  is  called  only  by  the  TC$TICKET 
(Traffic  Controller  TICKET)  module. 

TC$LOCATE$SEQ  works  in  exactly  the  same  way  as  the 
LOCATE $EVC  does  except  that  it  searches  for  sequencers  in 
the  Sequencer  Table  (SEQSTABLE)  instead  of  eventcounts  in 
the  EVC$ TABLE . 
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4.  Traffic  Controller  AWAIT  (TC$AWAIT) 

The  TC$AWAIT  is  an  inter-process  synchronization 
primitive  visible  to  the  user,  via  the  "GATE.  It  allows  a 
process  to  suspend  its  own  execution  pending  the  occurrence 
of  a  specified  event.  TC$AWAIT  is  called  with  two  input 
arguments,  (a  pointer  to)  the  name  of  the  eventcount  and  the 
value  (of  the  event)  to  be  awaited. 

Upon  invokation.  Await  locks  the  Active  Process  Table 
and  then  calls  the  Inner  Traffic  Controller  utility  function 
ITC$RET$VPTC  to  obtain  the  identity  of  the  running  virtual 
processor.  This  is  used  in  a  search  of  the  Active  Process 
Table  to  identify  the  process  which  invoked  the  TC$AWAIT. 

Once  the  calling  process  has  been  identified,  an 
implicit  call  is  made  to  the  TC$LOCATE$EVC  to  locate  the 
index  in  the  EVC$TABLE  of  the  input  argument  (eventcount 
name) .  Then  the  current  value  of  the  eventcount  kept  in  the 
EVC$ TABLE  is  compared  to  the  awaited  value  specified  in  the 
call.  If  the  event  has  not  yet  occurred  (viz.,  the  current 
value  in  the  EVC$TABLE  is  less  than  the  awaited  input 
argument  value) ,  then  the  process  will  enter  the  blocked 
state.  The  Value  of  Eventcount  Awaited  field  in  the  Active 
Process  Table  is  updated  with  the  awaited  argument  value  and 
the  process  is  placed  on  the  eventcount' s  Blocked  List  (see 
Figure  44) .  Otherwise,  if  the  event  has  already  occurred 
(viz.,  the  current  value  is  greater  than  or  equal  to  the 
awaited  input  argument  value) ,  then  the  process  is  not 
blocked  but  is  made  ready. 
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Finally,  in  both  cases,  TC$AWAIT  calls  the  TC$SCHEDULER 
to  schedule  the  highest  priority  ready  process.  Upon  the 
return  from  TC$SCHEDULER  it  unlocks  the  Active  Process 
Table. 

5.  Traffic  Controller  ADVANCE  (TC$ ADVANCE) 

The  TC$ADVANCE  is  an  inter-proces3  synchronization 
primitive  visible  to  the  user,  via  the  "GATE".  It  allows  a 
process  to  signal  the  occurrence  of  an  event.  It  updates 
the  eventcount  and  signals  those  processes  which  had  blocked 
themselves  for  this  event.  Thus  TC$ADVANCE  is  also  responsi¬ 
ble  for  invoking  the  preemption  mechanism. 

TC $ ADVANCE  is  called  with  one  input  argument,  (a 
pointer  to)  the  name  of  the  eventcount  being  advanced. 

It  first  locks  the  Active  Process  Table,  then  makes 
an  implicit  call  to  the  TC$LOCATE$EVC  to  locate  the  index  in 
the  EVC$ TABLE  of  the  input  argument  (eventcount  name) .  Then 
the  current  value  of  the  eventcount  in  the  EVC$TABLE  is 
incremented  by  one.  The  eventcount' s  Blocked  List  (sea 
Figure  44)  is  searched  for  processes  which  had  previously 
blocked  themselves  waiting  for  the  same  eventcount  to  reach 
this  value.  As  processes  are  found  that  should  be  awakened, 
viz.,  if  the  current  value  of  the  eventcount  in  the  EVC$ TABLE 
is  greater  or  equal  to  the  EVC$VALUE$AW  (awaited  eventcount 
value)  field  of  the  APT  corresponding  to  the  specific  process, 
then  these  processes  are  made  ready. 
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An  entry  in  a  temporary  array  of  physical  processors 
is  now  made  to  record  the  physical  processor  in  whose  local 
memory  the  newly  awakened  process  is  loaded  for  preemption. 
The  awakened  process  is  then  removed  from  the  eventcount's 
Blocked  List. 

Once  all  of  the  processes  to  be  awakened  have  been 
found,  TC$ADVANCE  determines  which  virtual  processors  must 
be  preempted.  This  is  done  for  each  of  the  previously 
flagged  physical  processors  by  first  assuming  that  all  of 
the  physical  processor's  TC-visible  virtual  processors  (two 
in  this  implementation)  should  be  preempted.  Then  the 
decision  is  made  as  to  which  ones  will  not  be  preempted. 

This  method  greatly  simplifies  the  algorithm.  First  a 
temporary  list  (array)  of  virtual  processors  is  initialized 
to  indicate  a  virtual  preempt  for  each  of  the  virtual 
processors.  The  Loaded  List  is  then  searched  to  find  those 
processes  which  should  be  running.  The  processes  which 
should  be  running  are  those  with  the  highest  priorities  that 
are  either  in  the  "ready"  or  the  "running"  states.  Asstiming 
that  there  are  2  virtual  processors  per  physical  processor 
used  for  multiplexing,  then  the  2  highest  priority  "ready" 
or  "running"  processes  in  the  Loaded  List  should  be  running. 
Any  lower  priority  processes  that  actually  are  running 
should  be  preempted.  TC$ ADVANCE  determines  which  of  the 
processes  that  should  be  running  already  are  running  and 
deletes  their  virtual  processors  from  the  preemption  list 
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(resets  the  preempt  flag  in  this  array) .  What  will  remain 
at  the  end  are  those  virtual  processors  that  are  to  be 
preempted. 

The  next  step  is  to  actually  issue  the  preempt 
interrupts.  The  temporary  preempt  list  is  checked  and  if  a 
preempt  is  indicated  for  a  virtual  processor,  the  Inner 
Traffic  Controller  module  ITC$SEND$PREEMPT  is  called  to 
actually  issue  the  preempt. 

TC$ ADVANCE  next  readies  the  process  which  invoked  it 
and  calls  the  TC$SCHEDULER.  Upon  the  return  from  the  TC$- 
SCHEDULER  the  Active  Process  Table  is  unlocked. 

6 .  Traffic  Controller  Ticket  (TC$TICKET) 

The  routine  TC$TICKET  is  also  used  in  the  inter¬ 
process  synchronization  and  communication  mechanism.  It  is 
the  only  operation  performed  on  sequencers.  It  expects  one 
input  argument,  (a  pointer  to)  the  sequencer  name  and  it  is 
visible  to  the  user  via  the  "GATE". 

When  invoked,  TC$TICKET  locks  the  Active  Process 
Table,  and  calls  implicitly  the  TC  $  LOCATE  $  SEQ  to  find  the 
index  in  the  global  sequencer  table  (SEQ STABLE)  of  the 
sequencer  name  given  to  it  as  the  input  argument.  It  then 
obtains  from  the  SEQSTABLE  the  current  sequencer  value 
(SEQSVALUE)  corresponding  to  the  specific  index  and  returns 
this  sequencer's  value  to  the  process  which  called  the 
TCSTICKER.  The  value  according  to  the  PL/M  86  language 
conventions  is  returned  to  the  accumulator  (AX)  register. 
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Before  returning,  TC$TICKET  increments  by  one  the 
value  of  the  sequencer  and  finally  unlocks  the  Active  Process 
Table. 

In  this  way,  TC$TICKET  returns  an  unique  sequencer 
value  with  every  invokation,  which  will  always  be  one  more 
than  the  last  value  returned  in  the  same  way  that  TC$ADVANCE 
increments  the  eventcount  value  (EVC$VALUE) .  This  is  the 
reason  why  eventcounts  and  sequencers  were  defined  as  "positive 
non-decreasing  integers". 

7 .  Traffic  Controller  Preemption  Handler  (TC$PE$HANDLER) 

The  TC$PE$HANDLER  is  not  a  separate  procedure  but  is 
just  a  label  in  the  main  program  of  the  TC. 

It  serves  as  the  virtual  preempt  interrupt  entry 
point  into  TC$SCHEDULER  and  is  invoked  only  by  the  Inner 
Traffic  Controller  Scheduler  (VPSCHEDULER)  in  the  course  of 
virtualizing  preempt  interrupts.  Actually  the  VPSCHEDULER 
transfers  the  program  control,  via  the  virtual  interrupt 
vector,  to  the  global  label  TC$PE$HANDLER.  Recall  that  the 
virtual  interrupt  vector  residing  in  the  PRDS  (VIRT$INT$- 
VECTOR)  is  initialized  to  point  to  the  TC$PE$HANDLER  label. 

The  TC$PE$HANDLER  first  locks  the  Active  Process 
Table,  then  calls  the  TC$SCHEDULER  which  will  find  the  highest 
priority  ready  process  and  bind  it  to  the  preempted  virtual 
processor.  Upon  return  from  the  TC$ SCHEDULER  the  program 
control  is  transferred  back  to  the  VRSCHEDULER ,  effecting  a 
"virtual  interrupt  return" . 
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8.  Await  For  Start  (AWAIT$FOR$START) 

This  module  is  a  part  of  TC$AWAIT  and  is  called  only 
once,  during  system  initialization,  by  the  MMGT  process.  It 
is  invisible  to  the  user. 

It  accepts  three  input  arguments,  the  index  of  the 
process  in  the  Active  Process  Table  assigned  by  the  CREATE$- 
PROCESS  (Create  Process)  module  discussed  in  paragraph  9 
below,  the  eventcount  name  and  the  eventcount  value  to  be 
awaited.  There  is  in  the  system  a  special  eventcount  named 
"START"  with  initial  value  zero.  The  second  input  argument 
is  the  name  of  this  special  eventcount  and  the  third,  the 
awaited  value,  which  is  always  one. 

Each  time  the  CREATE$PROCESS  is  called  to  create  a 
process,  the  last  statement  is  a  call  to  AWAIT $FOR$ START 
(Process,  Start,  1).  In  this  way  each  newly  created  process 
after  creation  is  set  to  the  blocked  state  awaiting  for  the 
special  event  START  to  reach  the  value  1.  Each  new  process 
is  added  to  the  blocked  list  (see  Figure  44)  for  the  event- 
count  START. 

9.  Advance  For  Start  ( ADVANCE$FOR$STAR$ ) 

This  module  is  a  part  of  TC$ADVANCE  and  is  also 
called  only  once  during  the  system  initialization  by  the  MMGT 
process.  It  is  invisible  to  the  user. 

It  accepts  one  input  argument  (a  pointer  to)  the  name 
of  the  eventcount  START.  Where  invoked  it  advances  (incre¬ 
ments  by  one)  the  value  of  the  special  event  START.  The 
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result  is  that  the  value  of  START,  initially  zero,  reaches 
for  every  new  process  the  awaited  value  of  1.  Then  using 
the  existing  signalling  mechanism,  (the  same  as  in  the 
TC$ ADVANCE  module) ,  AD VAN CE  $  F  OR  $  S  T ART  awakes  each  process  on 
the  START  eventcount's  blocked  list  and  sets  its  state  to 
ready . 

The  created  processes  are  now  in  contention  for 
processor  resources.  The  same  sequence  of  actions  will  be 
followed  as  in  the  case  of  TC$ADVANCE  except  that  ADVANCE $- 
FOR$START  doesn't  ready  the  calling  process  (which  is  the 
MMGT  process)  and  also  doesn't  call  the  TC$SCHEDULER  but 
merely  returns  program  control  to  the  caller,  the  MMGT 
process. 

10.  Create  Process  (CREATE$PROCESS) 

The  CREATE$PROCESS  module  provides  the  capability 
to  dynamically  create  processes.  It  is  called  with  one  input 
argument,  a  pointer  to  a  process  parameter  block  (PPB)  struc¬ 
ture  containing  all  the  information  necessary  to  initilize 
the  process ' s  stacks  and  enter  the  newly  created  process  into 
the  Active  Process  Table.  All  of  the  process'  segments  had 
previously  been  loaded  into  memory  by  the  system  loader,  as 
described  by  Anderson  [19] . 

CREATE$ PROCESS  first  locks  the  Active  Process  Table. 
The  next  step  is  to  enter  the  process  in  the  Active  Process 
Table.  To  create  this  entry  the  traffic  controller  uses  the 
parameters  passed  by  the  PPB  structure  (see  MMGT  Process  in 


previous  paragraph  J1  of  this  chapter) .  The  process  is  also 
inserted  into  the  Load  list  based  on  its  priority,  viz., 
CREATE$PROCESS  searches  down  the  LOAD$LIST  corresponding  to 
the  physical  processor  on  which  this  process  is  loaded  and 
sets  the  LOAD$THREAD  field  (see  Figure  44)  in  such  a  way 
that  the  currently  created  process  is  entered  immediately 
ahead  of  the  first  process  found  to  have  lower  or  equal 
priority. 

Then  CREATES PROCESS  initializes  two  stack  frames  for 
this  process:  the  KERNEL$STACK  and  USERSSTACK  corresponding 
to  the  kernel  and  user  domain  respectively.  In  this  way  the 
process'  address  space  is  divided  into  these  two  separate 
domains  of  execution.  The  kernel  stack  has  already  been 
discussed  in  Paragraph  E  of  this  chapter  (see  also  Figure  26) . 
The  user  stack  is  shown  in  Figure  48  and  the  relation  between 
these  two  stacks  in  Figure  49.  Since  in  the  PL/M-86  language 
the  stack  grows  downwards  (see  Figure  22)  by  keeping  the 
kernel  stack  above  the  user  stack  the  KERNEL$STACK  is  protect¬ 
ed  from  accidental  user  tampering  (viz.,  overwriting  KERNEL$- 
STACK  is  avoided) . 

The  location  of  these  stacks  and  the  initial  register 
values  (viz.,  initial  values  for  all  of  the  8086's  registers) 
for  the  specific  process  are  passed  by  the  PPB  structure  and 
used  in  the  initialization  of  the  stack  frames. 

Finally,  CREATE $ PROCESS  unlocks  the  Active  Process 
Table  and  calls  AWAIT$FOR$START  (Await  for  Start)  to  block 
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the  newly  created  process  and  sets  it  in  the  blocked  list  of 
the  special  eventcount  START. 

11 .  Traffic  Controller  Create  Eventcount  (TC$CREATE$EVC) 
This  module  is  visible  to  the  user  via  the  "GATE". 

When  invoked  by  an  application  process  it  creates  the  event- 
count  specified  by  this  process.  TC  $  C  REATE  $  E VC  is  called  with 
two  input  arguments,  (a  pointer  to)  the  name  of  the  eventcount 
to  be  created  and  the  desired  initial  value,  by  the  definition 
of  eventcount  [10]  this  value  should  always  be  zero. 

Upon  invokation,  TC$CREATE$EVC  locks  the  APT.  It  then 
calls  TC  $  LOCATE  $  EVC  to  determine  whether  or  not  the  eventcount 
had  already  been  created.  This  is  to  avoid  making  duplicate 
entries  (since  each  process  which  will  use  the  eventcount  must 
declare  at  least  the  name) .  If  the  eventcount  had  not  previous¬ 
ly  been  created  (viz.,  no  entry  is  found  in  the  Eventcount  Table 
with  the  same  name  as  given  in  the  input  argument)  then  an  entry 
is  made  in  the  Eventcount  Table.  The  name  is  copied  into  the 
Eventcount  Table  EVC$NAME  field  and  the  eventcount’ s  current 
value  (EVC$VALUE  field)  is  initialized  to  the  second  input 
argument.  Otherwise  no  entry  is  made.  When  the  entry  is  made 
in  the  Eventcount  Table  the  APT$PTR  field  is  initialized  to 
FFH  (the  nil  pointer) ,  meaning  that  there  is  no  process  in  the 
blocked  list  corresponding  to  this  eventcount  (empty  blocked 
list) . 

The  value  of  the  variable  EVENTS  (see  paragraph  H3  of 
this  chapter)  is  incremented  by  one  each  time  an  eventcount 
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is  created.  In  this  way  the  operating  system  keeps  track  of 
how  many  eventcounts  are  currently  used. 

Finally,  TC$CR£ATE$EVC  unlocks  the  APT  and  returns 
the  program  control  to  the  calling  procedure. 

12 .  Traffic  Controller  Create  Sequencer  (TC$CREATE$SEQ) 
This  module  is  also  visible  to  the  user,  via  the 

"GATE".  When  invoked  by  an  application  process  it  creates 
a  sequencer  in  exactly  the  same  way  that  TC$CREATE$EVC 
creates  an  eventcount.  The  only  difference  is  that  it  accepts 
one  input  argument,  (a  pointer  to)  the  name  of  the  sequencer 
as  defined  by  the  user.  The  initial  sequencer  value  is 
always  zero. 

The  operating  system  keeps  track  how  many  sequencers 
are  currently  used  in  the  system  by  using  the  variable 
SEQUENCERS  (see  paragraph  H9  of  this  chapter) . 

13 .  Traffic  Controller  Read  (TC$READ) 

The  TC$READ  module  is  also  visible  to  the  user,  via 
the  "GATE".  It  returns  the  current  value  of  an  eventcount  to 
the  calling  process.  It  is  called  by  one  input  argument,  (a 
pointer  to)  the  name  of  the  specific  eventcount. 

When  invoked,  TC$READ  locks  the  APT  and  then  calls 
the  TC$ LOCATE $EVC  to  obtain  the  index  of  this  eventcount  in 
the  eventcount  table  (EVC$TABLE) .  Using  this  index,  TC$READ 
obtins  the  current  value  of  the  eventcount  from  the  EVC$VALUE 
field  of  the  EVC$TABLE  and  returns  this  value  in  the  accumula¬ 
tor  (AX)  register. 
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Prior  to  returning  to  the  calling  procedure  it  unlocks 

the  APT. 

14 .  An  Overall  View  Figure 

After  finishing  the  detailed  description  of  the  ITC, 
system  processes  and  TC,  an  overall  view  of  the  two-level 
scheduling  and  multiplexing  technique  is  illustrated  in 
Figure  50.  This  view  is  similar  for  each  of  the  physical 
processors  in  the  system. 

At  the  ITC  level  (LEVEL  1)  the  left  most  and  right 
most  virtual  processor,  e.g.,  VP$START  and  VP$END  are 
permanently  bound  to  the  MMGT  and  IDLE  process  respectively. 
They  are  in  contention  for  physical  resources  (in  the  figure 
for  the  physical  processors) ,  but  they  are  not  in  contention 
for  user  process  scheduling.  The  remaining  two  central  VP's 
are  temporarily  bound  to  supervisor  processes  (user  or 
application  processes)  as  determined  each  time  by  the 
TC  $  SCHEDULER .  The  criteron  is  that  the  highest  priority 
process  will  be  scheduled  first.  In  the  case  when  no  super¬ 
visor  process  is  ready,  the  TC  invokes  ITC  IDLE$VP  (see 
paragraph  110)  which  loads  an  idle  process  on  the  VP.  The 
idle  process  will  actually  run  only  when  the  VP  to  which  it 
is  permanently  bound  (VP$END)  is  scheduled.  This  will  happen 
only  when  all  other  VP's  are  waiting  the  occurrence  of  events 
or  temporarily  bound  to  idle  processes  (i.e.,  when  there  is 
"no  work"  for  the  specific  physical  processor) . 
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WAITING 


/ 


RUNNING 


READY 


IDLE  WITH 
J>E$END  FLAG 
SET 


VP  #1 

I=VP$START 


VP 

VP 

VP  #K 

#  1+1 

#  1+2 

K=VP$END 
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VP  IS  WANTED  RP  IS  WANTED 

PERMANENTLY  BOUND  PROCESS  TEMPORARILY  BOUND  TO  VP 

VP  TEMPORARILY  BOUND  TO  RP 


FIGURE  50.  AN  OVERALL  VIEW  FOR  EACH  PHYSICAL  PROCESSOR 


The  ITC  VPSCHEDULER  schedules  VP's  on  the  physical 
processors.  The  criteron  is  that  each  time  it  schedules  on 
the  physical  processor  the  highest  priority  "eligible"  VP. 
Eligible  in  this  design  means  ready  or  in  the  idle  state, 
but  with  the  preempt  pending  flag  set. 

In  this  way  the  operating  system  supports  multipro¬ 
gramming  on  each  physical  processor  and  also  multiprocessing 
(concurrent  processing)  since  there  are  several  processors. 

The  transitions  of  the  processer  among  the 
"ready-blocked-run"  states  is  controlled  by  the  inter-process 
communication  and  synchronization  mechanism  and  also  the 
TCSSCHEDULER. 

The  transitions  of  the  VP's  among  the  "idle-waiting- 
ready  and  run"  states  are  controlled  by  the  inter-virtual 
processor  communication  and  synchronization  mechanism  and 
the  VPSCHEDULER. 

Finally,  the  hardware  interrupt  structure  is  used  for 
preemptive  scheduling  to  support  real-time  processing. 

L.  THE  SUPERVISOR 

1 .  General  Description 

In  a  general-purpose  computer  utility  the  "supervisor" 
provides  the  interface  between  application  programs  and  the 
kernel  of  the  operating  system  by  supporting  common  services 
such  as  development  tools  (e.g.,  editors,  compilers,  assemblers, 
linkers,  locaters,  loaders),  library  functions,  file  system  etc. 
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In  the  current  implementation  only  one  module  is 
needed  at  the  supervisor  level,  since  all  the  above  develop¬ 
ment  tools  are  supported  by  the  INTEL'S  MDS  system  (Micro¬ 
computer  Development  System) .  This  module  is  written  in 
assembly  language  and  is  called  "Gate"  or  "Gatekeeper" . 

Tnere  must  exist  a  way  to  link  each  user  (application) 
program  with  the  operating  system  in  order  to  have  as  a  result 
the  user  (application)  process  shown  in  Figure  25.  The  Gate 
is  this  "actual  linkage"  and  is  constructed  such  that  it  is 
the  only  operating  system  module  that  the  user  has  to  link 
to  his  program  in  order  to  access  kernel  functions  visible 
to  him. 


2 .  The  Gate  or  Gatekeeper 


The  Gate  exists  on  the  boundary  between  the  kernel 
and  supervisor  levels  of  abstraction  (see  Figures  4,  5  and  9) 
and  therefore  is  called  a  "software  ring  crossing  mechanism". 
It  is  utilized  to  ensure  that  the  kernel  is  "isolated"  and 


"tamperproof".  This  module  will  be  also  important  in  the 
future  if  the  system's  internal  security  is  considered.  This 
structure  is  specifically  designed  to  be  compatible  with  the 
future  version  of  the  8086  processor. 

The  system  services  visible  to  the  user  are:  TC$AWAIT, 
TC$ ADVANCE,  TC$TICKET ,  TC $ CREATE $EVC,  TC$CREATE$SEQ  and  TC$READ. 
All  these  modules  are  related  to  the  synchronization  and 
communication  mechanism.  It  is  noted  that  the  operating  system 
never  calls  (execute  the  code  of)  these  procedures.  They  are 


called  only  by  the  user  when  the  application  programs  need 
synchronization  support  (viz.,  when  an  application  program 
is  partitioned  into  asynchronous  interactive  parts) . 

The  corresponding  names  for  these  procedures  in  the 
GATE  are  AWAIT,  ADVANCE,  TICKET,  CREAT$EVC ,  C REATE $SEQ,  and 
READ  respectively. 

The  GATE  contains  the  "public"  declarations  for  these 
procedures  and  in  this  way  allows  the  user  to  call  these 
operating  system  procedures  in  exactly  the  same  way  that  any 
other  "external"  procedure  would  be  called. 

The  advantage  is  that  only  the  GATE  (a  very  small 
module)  is  required  to  be  linked  and  loaded  with  each  user 
process  and  not  the  entire  operating  system.  Furthermore, 
during  system  generation  [19] ,  the  GATE  can  be  located  in 
exactly  the  same  absolute  address  in  memory  for  all  of  the 
processes  loaded  on  a  single  microcomputer.  The  result  is 
that  the  GATE  segment  loaded  in  with  each  process  will  be 
overlayed  and  the  same  copy  will  be  shared.  This  minimizes 
the  amount  of  physical  memory  used  by  the  GATE. 

The  GATE  is  a  set  of  global  procedures  which  the 
user  programs  can  call  directly.  Each  of  the  user  accessible 
(visible)  kernel  functions  is  represented  by  one  of  these 
procedures.  Actually  they  only  set  up  the  required  para¬ 
meters  and  use  a  "trap"  feature  (INT  instruction)  to  effect 
the  call  to  the  real  procedure  of  the  kernel.  For  example, 
when  a  user  program  calls  AWAIT  then  the  GATE  using  the 
same  parameters  calls  TC$AWAIT,  and  son  on. 
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The  GATE  is  written  in  assembly  langauge  because  of 
the  stack  manipulation  that  must  be  done  for  parameters 
passing  between  PL/M  86  and  ASM  86  (PL/M  high  level  language 
and  assembly  language)  and  to  invoke  the  "trap  handler"  in 
such  a  way  to:  1)  determine  the  correct  kernel  entry  point 
(the  proper  procedure)  to  call,  and  2)  properly  pass  para¬ 
meters  to  the  kernel  procedures. 

The  GATE  consists  of  three  small  modules  called  GATE, 
trap  handler  and  trap  processes.  When  a  GATE  procedure  is 
called  by  a  user  program  the  parameters  are  moved  on  the 
stack  and  the  GATE  reaches  the  trap  handler  by  an  interrupt 
(e.g.,  an  internal  interrupt,  or  trap)  using  the  INT 
instruction.  The  trap  handler  transfer  program  control  to 
the  corresponding  trap  process  which  in  turn  invokes  the 
real  kernel  procedure  with  the  same  parameters  passed  on  the 
stack  by  the  user  program. 

This  has  the  effect  of  de-coupling  the  user  from  all 
the  operating  system  modules  below  the  Supervisor  level. 

The  software  provided  by  the  Gatekeeper  has  to  perform 
additional  functions  upon  the  kernel  entry  and  kernel  exit, 
as  shown  in  Figure  51. 

Figure  52  tabulates  the  required  format  for  all  of  the 
external  procedure  declarations  that  must  be  included  in  the 
user  programs  when  invoking  kernel  functions.  Of  course,  only 
the  kernel  functions  actually  invoked  need  to  be  externally 
declared  by  the  user  program. 
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Kernel  Entry 


1.  Mask  hardware  preempt  interrupts  in  the 
kernel . 

2.  Save  user  domain  registers  in  the  user 
stack  (user  domain) . 

3.  Switch  from  user  to  kernel  domain  (stack). 

4.  Save  user  domain  stack  segment  (SS)  register 
and  user  stack  pointer  (SP)  register  in  the 
kernel  stack. 

5 .  Check  arguments  and  invoke  appropriate 
kernel  entry  point. 


Kernel  Exit 


1.  Check  for  virtual  preempt  interrupts  (call 
CHECKS PREEMPT)  when  leaving  the  kernel 
(unmask  virtual  interrupt) . 

2 .  Save  kernel  domain  SS  and  SP  registers  in 
the  kernel  stack. 

3.  Restore  user  domain  SS  and  SP  registers. 

4.  Restore  user  domain  registers. 

5.  Unmask  hardware  interrupts. 

6.  Return  to  the  user  process,  execution  point 
in  the  user  domain. 


FIGURE  51.  KERNEL  ENTRY  -  KERNEL  EXIT 
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Creating  an  Eventcount : 


CREATE $EVC :  PROCEDURE (EVENTCOUNT ,  VALUE)  EXTERNAL; 

DELARE  EVENTCOUNT  POINTER,  VALUE  WORD; 

END; 


Creating  a  Sequencer: 

CREATE $SEQ:  PROCEDURE (SEQUENCER)  EXTERNAL; 

DECLARE  SEQUENCER  POINTER; 

END; 

The  Advance  Operation: 

ADVANCE:  PROCEDURE (EVENTCOUNT)  EXTERNAL; 

DECLARE  EVENTCOUNT  POINTER; 

END; 

The  Await  Operation: 

AWAIT:  PROCEDURE (EVENTCOUNT, VALUE)  EXTERNAL; 

DECLARE  EVENTCOUNT  POINTER, 

VALUE  WORD; 

END; 

The  Ticket  Operation: 

TICKET:  PROCEDURE (SEQUENCER)  BYTE  EXTERNAL; 

DECLARE  SEQUENCER  POINTER; 

END; 

The  Read  Operation: 

READ:  PROCEDURE (EVENTCOUNT)  BYTE  EXTERNAL; 

DECLARE  EVENTCOUNT  POINTER; 

END; 


FIGURE  52.  KERNEL  CALL  EXTERNAL  PROCEDURE  DECLARATIONS 


In  J.  Wasson  thesis  [8]  ,  there  is  a  whole  appendix 
(Appendix  A)  of  33  pages  with  programming  instructions  and 
examples  how  to  use  the  synchronization  mechanism  and  the 
operating  system.  It  is  considered  redundant  to  repeat  these 
instructions.  Instead,  in  Appendix  A  of  this  thesis  will  be 
incorporated  several  actual  operating  system  test  programs 
and  their  output. 
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V.  CONCLUSIONS 


A.  RESULTS 

The  principal  goal  of  this  thesis,  the  development  of  the 
kernel  of  a  real-time,  distributed  operating  system  for  a 
microcomputer  based  multiprocessor  system  was  met. 

This  operating  system  is  hierarchically  structured, 
layered  in  three  loop  free  levels  of  abstraction,  viz.,  the 
Inner  Traffic  Controller,  the  Traffic  Controller  and  the 
Supervisor,  and  fundamentally  configuration  independent. 

This  verifiable  loop  free  structure  was  demonstrated  with 
EXAMPLE  #6  in  the  Appendix  A. 

Furthermore,  at  each  level  of  this  hierarchical  structure 
the  corresponding  part  of  the  operating  system  consists  of  a 
set  of  understandable  modules  whose  interactions  are  clearly 
specified  and  strictly  enforced. 

The  result  is  a  relatively  small  and  easy  to  analyze 
operating  system  and  this  also  was  a  principal  goal. 

Since  the  kernel  is  small:  (1)  less  memory  is  spent  for 
its  storage  and  (2)  less  processor  time  is  spent  in  its 
execution.  This  advantage  of  less  memory  allows  physical 
distribution  of  the  kernel's  code  and  data  among  the  micro¬ 
computers  and  this  distribution  in  turn  helps  to  minimize 
system  bus  contention. 
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On  the  other  hand  the  layered  modular  structure  provides 
the  advantage  of  making  it  easy  to  debug,  test  and  analyze, 
ensuring  correct  operation  and  permitting  an  opportunity  to 
increase  performance  by  tuning. 

B.  FOLLOW  ON  RESEARCH 

Although  the  kernel  executes  correctly,  as  shown  in  the 
examples  of  appendix  A,  before  higher  levels  of  abstraction 
are  added  to  the  system,  a  more  formal  test  and  evaluation 
plan  should  be  developed.  Once  the  kernel  has  been  proven 
highly  reliable  then  the  follow  on  research  is  feasible  for 
the  reasons  explained  below. 

The  existing  stub  for  memory  management  process  solves 
the  two  hardest  problems  of  the  memory  management  functions: 
(1)  the  interface  with  the  kernel  and  (2)  the  needed  inter- 
virtual  processor  communication  and  synchronization.  Both 
capabilities  have  been  implemented  and  tested. 

The  hard  problem  for  adding  I/O  management  is  also  the 
inter-virtual  synchronization  mechanism  which  exists  and 
works  correctly.  For  I/O  management  one  more  VP  will  be 
added  on  each  physical  processor  permanently  bound  to  the 
I/O  process,  in  the  same  way  as  is  done  for  MMGT  and  IDLE 
process. 

It  is  also  possible  to  add  file  management  (by  dividing 
its  functions  among  kernel  and  Supervisor) .  Finally,  the 
process  oriented  structure  of  the  operating  system,  the 


215 


separation  of  the  address  space  of  each  process  intp  user  and 
kernel  domain  of  execution  and  also  the  existence  of  the  Gate 
lead  automatically  to  the  required  structure  for  internal 
security.  Additional  segmentation  hardware  is  needed  to 
control  the  access  (read,  write)  of  the  system's  and  user's 
subjects  (viz. ,  processes),  to  the  system  objects  (viz., 
segments).  The  needed  hardware  will  be  available  in  the 
anticipated  8086  successor. 
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APPENDIX  A 


SYSTEM' S  TESTING 

This  appendix  incorporated  six  examples  to  demonstrate 
the  use  of  the  operating  system  and  also  to  test  the  inter¬ 
process  communication  and  synchronization  mechanism,  the 
inter-virtual  processor  communication  and  synchronization 
mechanism  and  the  inter-real  processor  communication 
mechanism  (used  for  preemptive  scheduling  and  supported  by 
the  hardware  interrupt  structure) . 

For  each  example,  the  input  source  code  and  the  actual 
output  to  the  printer  are  incorporated. 

Four  of  these  test  programs  designed  and  implemented  by 
the  author  and  the  remaining  two  by  students  working  in  the 
"Electro-Optics  and  Signal  Processing  Laboratory"  of  the 
Naval  Postgraduate  School. 
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EXAMPLE  #1 


In  this  example  there  are  two  interactive  processes 
running  on  a  uniprocessor  system  under  the  operating  system. 
This  example  demonstrates  the  multiprogramming  capability 
and  also  the  use  of  the  inter-process  communication  and 
synchronization  mechanism. 

In  the  input  source  code  under  the  header  EXAMPLE  #1 
INPUT,  there  are  enough  comments  for  easy  understanding  of 
this  example.  Figures  53  and  54  are  provided  to  illustrate 
the  interleaved  execution  of  these  two  processes  and  how 
they  interact  using  the  synchronization  mechanism.  The 
output  on  the  printer  is  also  provided  under  the  header 
EXAMPLE  #1  OUTPUT. 

The  variables  A,  B  and  C  have  been  incorporated  and 
are  changed  before  and  after  entering  the  operating  system 
kernel  (e.g. ,  when  the  process  calls  ADVANCE  or  AWAIT) 
to  demonstrate  that  these  values  are  correctly  saved  and 
restored  from  the  per  process  stack. 
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EXAMPLE  #1  INPUT 


:  ec  la  re 

C  Z  - L  A  F  -- 


CELLAR; 


::s?l‘t 

«S  C 1 '  *  ' 

'-scr:*' 

>5C,;< »' 

»S ji(  *  ' 

vc  - t  V  ' 


2  Z  LT  A  *c 
V-ZSA ( = 


: ;  acf 

sm; 

3r?s 
3TT  i 

3TTE 

ETTE 

shall? 
shall? 
1  -?T£ 
i  ETTE 


initial  i 'ent^ino  ?3oc*i.  i?  has  hi; he?.  ??i;p: 

INITIAL  v'??DC*l.  EN7ERINC  CELA? 

INITIAL  i  'EXSCUTINC  IN  ??.0C*1 
INITIAL  ^  'END  C?  DE-ONSTRACIcN  "/ , 

I'il’PL  C'CrFHEN?  V‘U I  3?  C  = 

\LH\ 

‘tk*’; 

la:»;  'mm't . 

LATM'A-EOAS'); 


PEOCSDLPS  /2rCSID«?AR«.57C57ALiPAE1)  EXTERNAL; 
CECLAP.S  t7C$:rSPA!>«*  POINTER  , 

S7C$7AL$?AR'4  rord; 


Is  PROCEDURE  ( EfCSIDSPAR'*)  EXTERNAL; 
3ECLAPE  iVCjISSPAPN  POINTER; 


CJTSCHAE:  FROCSE JRE( CHAR ) ; 

TEC  LAPS  CHAR  3TTS; 

CO  ifKILE  (  INPdT(aDAH)  AND  01H) 

ent; 

r'v’T?(JT(  3D3H)  «  char; 


3TTJ  HEX:  PROCEDURE!  S } ! 

ZZCZIP2  3  3TTE< 

DECLARE  AScii(*)  BITE  DATA!  'ai2I<i5£7?3A3c: E" ' ) ; 
CALL  O  JTSCH AR  ( A.3CI  I  (3 HR ( 5  ,4)  AND  3FH ) )  ! 

call  octschapusdiio  and  ari)); 


''AIN  ?  R  0  0  R  A  * 


,*«***••/ 


/’ *  ?R0C#t  IS  THE  RICHER  PRIORITT  PROCESS  */ 

CALL  CLTSCRAPJCP ) ! 

C»LL  OJTSCHAP'LE) ! 

CALL  OJTiCHA.RILF) J 
CC  I  «  2  TO  3i! 

CALL  OffTSCKARirSOid); 

Esc ; 

CALL  CLTSCHAStCR}; 

CALL  OLTSCHAR  (LD  5 


A  *  3*5*25; 

C  »  «*iz; 

CALL  OarsCKARfCP ) ; 
call  outschap'lfi ; 

C  *  LL  OL’TSCKA.P.'LD  ; 

13  :  «  ?  :o  22; 

call  outscra?;''S02( r ); 
EM! 

call  ojtschar'cr) ; 
call  cltsc ha?.( l?)  ; 
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CG  1  *  3  TO  223  J 
3  A  L-  T 1  Hi.!  cz4  )  v 


/■»  the  initial  value  or  events  delta  ass  ahega  are  s  */ 

IALL  AWAIT!  AOELTa  ,2)  I 

/«  ?EC‘75E  THE  VALUE  IS  THE  CALL  STATEMENT  IS  2,  GREATER  THAN  THE  */ 

/*  INITIAL  VALUE  »  3,  AWAIT  WILL  SUSPEND  THE  EXECUTION  OF  THAT  */ 

'*  '.CALLING)  PROCESS  AND  TCE  SCHEDULE?  WILL  SCHEDULE  THE  HIGHER  «/ 

,•»  rSIOSITT  •  P  3“  THE  REGAINING  PROCESSES.  PROCwl  WILL  GO  TO  THE  */ 

i~  SLOGiED  ST*  TE  */ 

CALL  OUTSCHAR ( OR ) ! 

call  cutschap'l ?i ; 

C*LL  OUTSCHAR ' LE) 5 
LO  I  *  3  TO  id; 

ZklZ  0U?$CRAP<'*SJ3(I)  ).* 

CALL  OJTSCHAR (OR ) i 
CALL  OUTSCHAR ( L?) 5 

CALL  OUTSCHA*. CR ) J 
CALL  OJTSCHAR) L?) ! 

CALL  OCTSCSAR(LF) » 

CO  I  *  a  TO  22: 

CALL  OJTSCHAR( f'S 32(I))i 

end: 

CALL  OUTSC HAP ( C? ) i 
CALL  OUTSCHAR ( L?) i 

3C  I  -  3  TO  2325 
CALL  TINE(ZSa); 

:  i  r  . 


A  » 

»  * 

CALL  AWAIT  (.VW-SGA.l); 

/*  SINCE  1  IS  GREATER  THAN  PRESENT  VALUE  0?  'WflSGA  »  2,  PR0CW1  */ 
/•  .ILL  GO  AGAIN  TO  THE  3L0CTED  STATS  AND  SCHEDULER  WILL  SCHS-*/ 
/“  DOLE  PR0C*2  */ 

CALL  OJTSCHAR (!?.)! 

CALL  CUTSCHAP(LF) ! 

CALL  OUTSCHAR! LE) 5 
TO  I  -  l  TO  1?; 

CALL  OUTSCHARO-SISd)); 

EnD; 

CALL  OUTSCHAR <CR) 5 
CALL  OUTSCHAR ( L?) i 

CALL  OUTSCHAR! CR) J 
CALL  OUTSCHAR! LF)  I 
CALL  OUTSC HA? ! LF ) ! 

DC  I  •  3  TO  ?2J 

CALL  OJTSCHAR  (."'SJ2!  I )  ) : 

•  no; 

CALL  OUTSCHAR  f  C? ) J 
CALL  OUTS  CHAR! LE) I 

DC  I  *  3  TO  2335 
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?5  ?  .  £  5  C 


ls=l 


/ 


’rsS'icsciiJ 

teclare  a. 5,:)  integer. 

;  *'3®:; 

tstlapz  -soii*'  3tte  initial  .'entering  ??.oc»2.  it  has  lower  ppicpitt 

-SG2(*'  BITE  INITIAL  . 'PP0C*2.  tNT5FI.NO  CELAT 
'S03'*'  BITE  INITIAL  i  'EXECUTING  IN  ?R0C*2  '!, 

0®  LI  TER  ALL!  'PCS'. 

:r  LiTER'LLr  # «. a. ; 

TETLaPS  TILT  A '  5 '  BTTE  T  ‘  T  A(  'TELTAi  * } , 

W-EGAiS'  'TIE  TATA  ( ''MESAS!'); 

‘WAIT:  PROCSEURE  (SVCS  irSPAR-.SVCSVALSPA?!-}  EXTERNAL; 

TECLaP.E  EVCSIOSPARM  POINTER, 

EVCS  V  ALS  ?  A  -  word; 


AT'ANCE:  PFOCEOtIF.E  (EVCSIOSPARM)  EXTERNAL  i 
IIOLARi  EVC S IE$  PAR-  POINTER; 

ENT; 

OJTSCHAR  :  PROCEDURE!  CHAR  )  ! 

ISCLARE  OSAR  BTTE; 

to  WHILE  (INPUT!  30  AH)  AND  J1R)  =*  2! 

END  i 

OUTPUT (eta®)  -  ohar; 

I  no  ; 


,«««»««,  «c==«=>  -  A  I  :J  PROGRAM  <■»*»*»«  *»*****«/ 

/*  ?RTC*2  13  T“E  ICWS?  ?°IOPITT  PROCESS  */ 

TALL  OJTSCHAR* JR)J 
TALL  0 JT5C  ?A? '  L? ) » 

C  *  LL  0 JTSCHAR ( L;  )  ; 

TO  I  *  3  TO  £=; 

CALL  OtITSCHAP. (-S5K  I ) ) ; 

TALL  OUTS  CHAR ( CR )  J 
TALL  OJTSC HA? * LF)  i 

a  =■  13 ; 

=  *  a.*13; 

:  *  3*a; 

TALL  ‘OTA.NCEC-OELTA)  ; 

/*  EVENT  TELT*  HAS  NOW  THE  VALUE  1,  BUT  PR0C#1  CONTINUES  SLSEPINO  */ 
/•  UNTIL  THE  EVENT  TELTA  WILL  REACH  THE  VALUE  2  »/ 

CALL  OJTSCHAR ( CR  )  ! 

TALL  OL’TSC SAP  ( L? )  i 
CALL  OCTSCHAR(LJ) ! 

TO  I  -  3  TO  22! 

CALL  CCTSCHAP ( -S32( I ) ) » 

EM  i 

TALL  TL'TSCHAR(CR); 

CALL  OUTSCKARM*)  ; 

*.  0  *  —  0  -  0  (4>,  , 
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i  "/ 


_ : .1  l i.  :i-e'F;3;; 

1  ! 

/«  INITIAL  VALUE  OF  EVENTS  FELT*  ‘C  A'iCA  >.32 
0  =  c-lj: 

call  aivanck atilta ) ; 

/*  -TENT  I ELTft.  REACHES  '/ALOE  2.  SO  ADVANCE  WILL  AVALS  ?°CC*1.  1 M  */ 

/«  *  iso  jill  if:  ?soc#2  son  :o  the  ?.e>:t  hade.  thin  :hf  *, 

/*  :  CHEDL’LE?  *  ILL  SCHEDULE  THE  H I JHF?  ?SIC?I?T  RE-TA  IN  I. *3  ?s0C2Si  */ 
/»  <  IN  0J9.  CASE  ?ROC*l )  .  */ 

C ALL  CLTSCHAR'C?: ; 

C  1  LL  yjTSCKA~.!LT)S 
•CALL  OLr:$CdAR(LF) » 

:c  :  -  3  :o  to; 

CALL  DPTSCHAR (MS02( I) ) ! 

END  I 

CALL  3UTSC HAR( CR ) > 

CALL  OL’TSCfiAH(lF); 

CALL  DJTSCHAR(CR) ; 

CALL  CUT?CHA?.(LF)  i 
CALL  OCTSCKAF ( LF) ! 

LO  I  »  i  TO  22; 

call  outschar (mso2( i ) ) ; 
em; 

CALL  OarsCHARfCP.); 

CALL  OUrsCHAR(LF) ! 

DO  I  »  3  TO  23 Hi 
CALL  1 1  ■-  E  ( 2  5  K ) ; 

end; 

c  =  c*S3; 
s  >  0*2; 

a  »  3*5! 

call  advanceov'iega)  ; 

/*  THE  EVENT  J^EGA  REACHES  NOV  THE  VALLE  1,  SO  ADVANCE  HILL  */ 

/*  A«AEE  ?ROC*l  AND  SET  PROC»2  IN  REACT  STATE.  THEN  THE  SCHE-*/ 

/*  IJLFR  HILL  SCHEULE  PROC#l  (SINCE  IOTR  PROCESSES  ARE  NOW  IN*/ 

/*  THE  SEADT  HATE  AND  ?RCC#1  HAS  HIGSEF  PRICHITT.  */ 

CALL  OOTSCHAR(CR) ; 

CALL  OOT5CHAR(L?) ! 

CALL  OUTSCKAR(LF) ! 

DO  I  -  i  TO  u; 

CALL  0UTSCHA?(^SC3(I)); 

end: 

CALL  OOTSCHAR ( CR ) ; 

OALL  OoTSCHAR'L?)  ! 

CALL  OOPSCHAE(CH); 

CALL  COTSCHARfLF) ! 

CALL  CJTSCHAR(LF) ! 

DO  I  «  3  TO  22; 

CALL  0L’TSChA3(rS32(I)); 

end; 

CALL  ODTSCHAR'CR); 

CALL  O'JTSCHAR'LF)  ! 

DO  I  «  3  TO  233! 
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EXAMPLE  #1  OUTPUT 


ENTERING  PROC#l.  IT  HAS  HIGHER  PRIORITY 

PROC#l.  ENTERING  DELAY 
ENTERING  AWAIT 

ENTERING  PROC#Z.  IT  HAS  LOWER  PRIORITY 
ENTERING  ADVANCE 

PROC*Z .  ENTERING  DELAY 
ENTERING  ADVANCE 

EXECUTING  IN  PR0C#1 

PROC# l .  ENTERING  DELAY 
ENTERING  AWAIT 

EXECUTING  IN  PROC*Z 

PROC#Z .  ENTERING  DELAY 
ENTERING  ADVANCE 

EXECUTING  IN  PROC# 1 

PROC#  1 .  ENTERING  DELAY 
CURRENT  VALUE  OF  C  -  03E8 

ENTERING  AWAIT  ‘ 

EXECUTING  IN  PROC#Z 

* 

PROC#Z.  ENTERING  DELAY 

l 

ENTERING  ADVANCE  4 
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EXECUTING  IN  PR0C#1 


END  OF  DEMONSTRATION 
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BLOCK  STATE 


l  WMEGA  =  1 

OUTPUT  MSG  3 

OUTPUT  MSG  2 
pELAY 

C  = 

■  CALL  AWAIT  (DELTA,  2U 


BLOCK  STATE 


DELTA 


OUTPUT  MSG  4 
END  OF  PROC  #1 


OUTPUT  MSG  3 
DELAY 

C  =  C  +  50 
B  =  C  *  2 
A  =  B  *  5 

jBall^advanceTwieg^ 


READY  STATE 


OUTPUT  MSG  3 

OUTPUT  MSG  2 
DELAY 
B  »  A  *  2 

(c^l^^ctTdelt^ 

END  OF  PROC  #2 


EXECUTING  IN  PROC  #2 
PROC  #2.  ENTERING 
DELAY 


ENTERING  ADVANCE 

EXECUTING  IN  PROC  #1 
PROC  #1.  ENTERING 
DELAY . 

CURRENT  VALUE  OF 
C  =  03E8 

ENTERING  AWAIT 

EXECUTING  IN  PROC  #2 
PROC  #2.  ENTERING 
DELAY. 


ENTERING  ADVANCE 


EXECUTING  IN  PROC  #1 
END  OF  DEMONSTRATION 


FIGURE  54.  INTERLEAVED  EXECUTION  OF  TWO  PROCESSES 


c 


228 


EXAMPLE  #2 


In  this  example  there  are  two  interactive  processes 
running  on  a  uniprocessor  under  the  operating  system.  These 
two  processes  simulate  the  image  processing  processes  CLUTTER 
SUPPRESION  AND  FILTER  DESIGN.  The  data  comes  into  the  micro¬ 
computer  as  frames  of  images  and  an  extensive  use  of  the 
synchronization  mechanism  is  required. 

Following  the  comments  in  the  input  source  code  under 
the  header  EXAMPLE  #2  INPUT  and  the  output  messages  under 
the  header  EXAMPLE  #2  OUTPUT,  it  is  possible  to  follow  the 
interleaving  execution  and  interaction  of  these  two  processes. 
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EXAMPLE  #2  INPUT 


/*  file  ppocai.sac  i£  -at  */ 
upps-odule:  do; 

CFCDARE  I  3TTE! 

DECLARE  D?  LITESA.LLT  '  3  D  H ' , 

IT  LITERA  LLT  '3Ac'T 

:  id  la?  E  ?  mi; 

DZCDA’E  C5!P?(5'  3TTZ  DATA  (  'CS  UP0?  ')  ; 

IZCLARI  “LTZS ( 5 )  PTTE  DATA! 'FLEES?')  ; 

CLAPE 

SDK*)  BYTE  INITIAL  l'?50C*l.  INITIAL  ENTST  INTO  CLUTTER  SUPPRESSION 
5C2 ( * )  SITE  INITIAL  ('PR3C*1.  WAIT  FOR  LATA  REALT 

S  D3 ( *)  PTTE  INITIAL  ('?®CC*1.  PERFORMING  CLUTTER  SUPPRESSION  ON  FRAME 
3  G4 ( * '  RTTE  INITIAL  l'?ROC*l.  ADVANCE  FILTER  DESIGN  E7ENTCOUNT 

AWAIT:  ?°3CZDUSS(  SVCS[D$PAR.M,3VC$?ALSPA?M)  EXTERNAL; 

DECLARE  IVCSIDSPARM  P3 INTER , 

3VC?7AL$PARM  WORD! 

end; 

ADVANCE:  PROCEDURE! E7C$ IDSPARM)  EXTERNAL; 

DECLARE  S7C$m?ARM  POINTER! 

end; 

3UT5CHAR:  PROCEEURE(CRAR )  ; 

DECLARE  CRAR  BYTE,* 

DO  WHILE  !  INPUT!  3DA.H)  AND  01H)  «=  3!  END; 

OUTPUT' 3I3H)  -  CRAR; 

end; 

OUTSHET:  PROCEDURE! 3) ; 

DECLARE  3  3TTE  > 

DECLARE  ASCII!*)  BTTE  DATA  (  '31234=5799A3CDSF  ' ' ! 

CALL  3UTSC3 AR( ASC 1 1 (SHR ( B ,4 )  AND  0FH)); 

CALL  OUTJCHAR ( ASCI I { 3  AND  0?H) ) ; 

END! 

I  *  si: 

CALL  OUTSCRAR(LF) ; 

CO  Z  *  3  TC  46! 

CALL  3UT$CHAR(MSGl(Z))i 

end; 

CALL  CUT$CHAR(CR); 

CALL  CUTSCHAP(LF)  ! 

CALL  3'JT$CHAR(  LF  )  * 

DO  WHILE  (I  O  54); 

CALL  3UT5CHAP! L: ) ! 

DO  Z  •  t  TO  46! 

CALL  0UT>CRAR(*S32(Z)); 

END; 

CALL  OUTSCHARf  CP.) ; 

CALL  OUTSCRAP(LF); 

CALL  0UTSC8AR(L?l; 


CALL  MAITOCSUPP.I): 


:  =  i  -  1; 

CALL  3’JT$CEA?  (  L~' ; 

:o  z  =  «:  -0  48 ; 

"all  out?:“ar!',s:3(:i 
lnl: 

call  :j:5E£t(I}.; 
call  rc?scf»AP( c3 ; ; 

CALL  2L'?SCHAn(L?); 

CALL  3  JTJCSAP. ( L? )  > 


23  Z  =  i  TC  230? 

CALL  TI^Et  230)  ; 

£ur; 

CALL  C'JTSCHAR(LF)  ? 

23  Z  »  7  TO  46 i 

CALL  3CT5CHAR(f<S34(:)); 
ENT! 

CALL  rJT$CEAR(CS)i 
CALL  33T3CHAR { L? ) ! 

CALL  2UT5CHAR ( LP ) ! 

CALL  ALVANCE(@?tDE$)i 

ENC  ?  /*  iHILE  */ 

NT?  /»  -OCCLE  V 
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FILE  ?P0C32.3BC  Is  v,*.r  */ 

i$S'-3LJLi:  TCi 

:e:ub£  :  Errs: 

liCLAP.I  3?.  LITERALLY  ’21H' , 

IT  LITSP ALLY  'DAH'; 

declare  z  cy:e; 

liCLAP.I  CS3PP(S)  3TTE  DATA  (  'CStJPPt' )  , 

DECLARE  FLDES(S)  3TTS  DATA( 'FLDESS')  ,* 


LARZ 

Zl(*'  3TTE  INITIAL  (  '?R30»2 .  INITIAL  ENTRY  INTO  FILTER  LESION  '), 
C2(«'  PTTI  INITIAL  ('PRCC#2.  AWAIT  FOR  DATA  READY 
Dif*)  3TTZ  INITIAL  ('PR3CW2.  PERFORMING  FILTER  DESIGN  ON  FRAME:  ') 
C4(«)  3YTE  INITIAL  i'?P0C»2.  ADVANCE  IL'JTTSR  SUPPRESS  ICN  EVENTCOUN 

AWAIT:  PP3C£:CP.£(EVC$ID?PAR>\S7C$7AL$PARM)  EXTERNAL  > 

DECLARE  EVC$ IDS  FARM  POINTER, 

SVCSVALSPARM  WORD; 

enc; 

advances  ?socedop.e(et:?id5parm)  sxtshnal; 

CECLAPE  2VCS I3SPARM  POINTER,* 

END ; 

3UTSCHAR:  PROCEDURE ( CHAR ) ; 

DFCLAPF  GEAR  BYTE: 

CO  WHILE  (INPJT(2CAH)  AND  31R)  -  0,*  ENT,* 

_3U??tJT(3i)9R)  *  CHAR! 

end; 


O’JTSHEX:  PP.3CEL3RE ( B )  i 
DECLARE  3  3YTS , 

ASCII ( *5  ETTE  DATA  (  '0123455755 ABODE? ') ! 
CALL  3GTSCHAR (ASCII(3RR(B,4)  AN!  ZFH ) ) ; 

IALL  3UT»CHAR(ASCII(3  AND  3FH))i 


:  *  0; 


DO  Z  •  3  TO  40! 

CALL  outschar(msgiu)  ); 
ENT, 

CALL  3UTSCRi?( CR )  * 

CALL  3DTSCHAR(L7); 

CALL  DUTJCHAP ( L? )  i 

DO  WHILE  (I  <»  S4); 

CALL  3UT SCRAP (LF); 

10  Z  »  £  TO  23; 

CALL  CuT$CSaP(n532(Z)).* 
inL; 

CALL  3 JTSCH A P ( CR ) ; 

CALL  3D TSCHARIL?;,* 

CALL  dutschapuf:  ; 

CALL  AWAIT(?fLLES.I); 
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i; 


zo  z  *  !  ro  z«y); 

zt.il  ri!«l(25e); 
iHZ; 

CALL  3!JTSCS»MLr  ) ; 

10  z  *  z  to  42; 

call  Co?5C“ASt'*sa3fz; 

£nl  ; 

call  carjmo; 

CALL  C,JTjCHA»(CP); 

CALL  3TCSCHAP(L?) J 
CALL  3JT5CR  A?  (  LF ) 5 

CALL  CO??CSAP.(LF); 

L3  1  =  0  CO  461 

CALL  3UT$CHAR(f'SC4(Z  )  )  i 

r ; 

CALL  SL'TSCHAPtC?.); 

CALL  :mCHA?.(L?); 

CALL  3UT5C3A8(LF) i 

CALL  » EVANCE( 3CS3PP ) ! 

EMC;  /*  rfHXLE  */ 

f,0;  /•'iODCLE  */ 


233 


EXAMPLE  OUTPUT 


PROC# 1 .  INITIAL  ENTRY  INTO  CLUTTER  SUPPRESSION 

PROC# l .  WAIT  FOR  DATA  READY 

ENTERING  AWAIT 

PROC#l.  PERFORMING  CLUTTER  SUPPRESSION  ON  FRAME:  01 
PROC# 1 .  ADVANCE  FILTER  DESIGN  EVOTIOOUNT 

entering  advance 

PROC# 1 .  WAIT  FOR  DATA  READY 

ENTERING  AWAIT 

PROC#Z.  INITIAL  ENTRY  INTO  FILTER  DESIGN 
PROC#2.  AWAIT  FOR  DATA  READY 

ENTERING  AWAIT 

PROC# Z .  PERFORMING  FILTER  DESIGN  ON  FRAME:  01 

PROC#Z.  ADVANCE  CLUTTER  SUPPRESSION  EVENTCCUNT 

ENTERING  advance 

PROC# I .  PERFORMING  CLUTTER  SUPPRESSION  ON  FRAME:  02 

PROC# 1 .  ADVANCE  FILTER  DESIGN  EVENTCOCNT 

ENTERING  ADVANCE 

PROC#l.  WAIT  FOR  DATA  READY 

OTTERING  AWAIT 
PROC#Z.  AWAIT  FOR  DATA  READY 
OTTERING  AWAIT 
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PR0C#2.  PERFORMING  FILTER  DESIGN  ON  FRAME:  02 


! 

i 

i 

i 
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PROC*2.  ADVANCE  CLUTTER  SUPPRESSION  EVENTCOUNT 

ENTERING  ADVANCE 

PROC# 1 .  PERFORMING  CLUTTER  SUPPRESSION  ON  FRAME:  03 

PROC# 1 .  ADVANCE  FILTER  DESIGN  EVENTCOUNT 

ENTERING  ADVANCE 

PROC# I .  WAIT  FOR  DATA  READY 

ENTERING  AWAIT 

PROC# 2 .  AWAIT  FOR  DATA  READY 

ENTERING  AWAIT 

PROC# 2 .  PERFORMING  FILTER  DESIGN  ON  FRAME:  03 

PROC# 2 .  ADVANCE  CLUTTER  SUPPRESSION  EVENTCOUNT 

ENTERING  ADVANCE 

PROC# 1 .  PERFORMING  CLUTTER  SUPPRESSION  ON  FRAME:  04 

PROC# 1 .  ADVANCE  FILTER  DESIGN  EVENTCOUNT 

ENTERING  ADVANCE 

PROC# 1 .  WAIT  FOR  DATA  READY 

ENTERING  AWAIT 

PROC# 2 .  AWAIT  FOR  DATA  READY 

ENTERING  AWAIT 

PROC# 2 .  PERFORMING  FILTER  DESIGN  ON  FRAME:  04 
PROC# 2.  ADVANCE  CLUTTER  SUPPRESSION  EVENTCOUNT 


i 


t 
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ENTERING  ADVANCE 


PROC#l.  PERFORMING  CLUTTER  SUPPRESSION  ON  FRAME:  05 

PROC* 1 .  ADVANCE  FILTER  DESIGN  EVENTCOUNT 

ENTERING  ADVANCE 

PROC*l.  WAIT  FOR  DATA  READY 

ENTERING  AWAIT 

PROC# 2 .  AWAIT  FOR  DATA  READY 

ENTERING  AWAIT 

PROC# 2.  PERFORMING  FILTER  DESIGN  ON  FRAME:  05 

PROC# 2 .  ADVANCE  CLUTTER  SUPPRESSION  EVENTCOUNT 

ENTERING  ADVANCE 

PROC# 1 .  PERFORMING  CLUTTER  SUPPRESSION  ON  FRAME:  06 

PROC# 1 .  ADVANCE  FILTER  DESIGN  EVENTCOUNT 

ENTERING  ADVANCE 

PROC#!.  WAIT  FOR  DATA  READY 

ENTERING  AWAIT 

PROC# 2 .  AWAIT  FOR  DATA  READY 

ENTERING  AWAIT 

PROC# 2.  PERFORMING  FILTER  DESIGN  CN  FRAME:  06 
PROC #2 .  ADVANCE  CLUTTER  SUPPRESSION  EVENTCOUNT 
ENTERING  ADVANCE 

PROC»l.  PERFORMING  CLUTTER  SUPPRESSION  ON  FRAME:  07 
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PROC# 1 .  ADVANCE  FILTER  DESIGN  EVENTCOUNT 

ENTERING  ADVANCE 

PROC#  l .  WAIT  FOR  DATA  READY 

ENTERING  AWAIT 

PROC# 2.  AWAIT  FOR  DATA  READY 

ENTERING  AWAIT 

PROC# 2 .  PERFORMING  FILTER  DESIGN  ON  FRAME'.  0? 

PROC# 2 .  ADVANCE  CLUTTER  SUPPRESSION  EVENTCOUNT 

ENTERING  ADVANCE 

PROC# 1 .  PERFORMING  CLUTTER  SUPPRESSION  ON  FRAME:  08 

PROC# I.  ADVANCE  FILTER  DESIGN  EVHfTCOUNT 

ENTERING  ADVANCE 

PROC# 1  *  WAIT  FOR  DATA  READY 

ENTERING  AWAIT 

PROC#2.  AWAIT  FOR  DATA  READY 

ENTERING  AWAIT 

PROC#2.  PERFORMING  FILTER  DESIGN  CN  FRAME!  08 

PROC# 2.  ADVANCE  CLUTTER  SUPPRESSION  EVOfTCOUNT 
ENTERING  ADVANCE 

PROC# 1 .  PERFORMING  CLUTTER  SUPPRESSION  ON  FRAME:  09 
PROC# 1 .  ADVANCE  FILTER  DESIGN  EVENTCOUNT 

ENTERING  ADVANCE 
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EXAMPLE  #3 


The  input  source  code  for  this  example  is  exactly  the 
same  as  for  the  previous  example.  The  difference  is  the  output. 
The  output  under  the  header  EXAMPLE  #3  OUTPUT  has  more  output 
messages.  In  fact  in  every  module  of  the  operating  system 
has  been  incorporated  at  least  one  output  message  as  shown 
in  Figure  55. 

In  this  way  the  debugging  and  checking  becomes  easier. 

Also  it  is  possible  to  follow  the  flow  of  program  control 
between  several  modules  of  the  operating  system. 

The  higher  priority  process  is  PROC01  (CLUTTER  SUPPRESSION) 
with  priority  40  and  the  lower  priority  is  PROC02  (FILTER 
DESIGN)  with  priority  41. 

The  address  space  descriptor  for  the  first  process  (the 
base  of  its  "per  process  stack")  is  equal  to  6000H(this 
appears  as  600  because  of  INTEL'S  monitor  convention),  for  the 
second  it  is  7000H  and  for  the  idle  process  it  is  5000. 
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LEVEL 

MODULE 

OUTPUT  MESSAGE 

CHECKVIRTINT 

ENTERING  CHECKVIRTINT 

ITC$RET$VP 

ENTERING  ITC$RET$INT 
RUNNING$VP$ID  = 

ITC $ LOADS VP 

ENTERING  ITC$LOAD$VP 

LOADING  VP  NUMBER: 

PRIORITY  FOR  THIS  VP  IS: 

NEW  DBR  FOR  THIS  VP  IS: 

ITC 

CHECK$PREEMPT 

ENTERING  CHECKPREEMPT 

GETWORK 

ENTERING  GETWORK 

SELECTED$DBR  = 

RUN$THIS$VP 

ENTERING  RUNTHISVP 

SET  VP  TO  RUNNING:  VP  = 

ITC$SEND$PREEMPT 

ENTERING  ITC$SEND$PREEMPT 

LOCKVPM 

ENTERING  LOCKVPM 

UNLOCKVPM 

ENTERING  UNLOCKVPM 

RDYTHISVP 

ENTERING  RDYTHISVP 

SET  UP  TO  READY:  VP  = 

TC$SCHEDULER 

ENTERING  TC$ SCHEDULER 

TC $ LOCATE $EVC 

ENTERING  TC$LOCATE$EVC 

TC 

TC$ AWAIT 

ENTERING  AWAIT 

TC$ ADVANCE 

ENTERING  ADVANCE 

TC$PE$HANDLER 

ENTERING  TC$PE$HANDLER 

FIGURE  55.  OUTPUT  MESSAGES  OF  THE  OPERATING  SYSTEM'S  MODULES 


EXAMPLE  #3  OUTPUT 


ENTERING  CHECKVIRTINT 
ENTERING  LOCKVIM 
ENTERING  RDYTHISVP 
ENTERING  ITCJRETJVP 

RUNNINGJVP5ID  -  00 

SET  VP  TO  READY:  VP  -  00 

ENTERING  GETWORK 

S ELECTED JD BR  »  OS 00 
ENTERING  RUNTHISVP 
SET  VP  TO  RUNNING:  VP  =  01 

ENTERING  UNLOCKVPM 
ENTERING  CHECKPREIMPT 
ENTERING  ITCJRETJVP 

RUNNINGJVPJ ID  -  01 

ENTERING  TCSPEJHANDLER 
ENTERING  TO $ SCHEDULER 
ENTERING  ITCJRETJVP 

RUNNINGJVPJ ID  *  01 

ENTERING  ITCJLOADJVP 
ENTERING  ITCJRETJVP 

RUNNINGJVPJ ID  »  01 

LOADING  VP  NUMBER:  01 

PRIORITY  FOR  THIS  VP  IS:  40 
NEW  DBR  FOR  THIS  VP  IS:  0600 
ENTERING  GETW3RK 

S ELECTED JDBR  »  0600 

ENTERING  RUNTHISVP 
SET  VP  TO  RUNNING:  VP  »  01 

ENTERING  UNLOCKVPM 
ENTERING  CHECKPREEMPT 
ENTERING  ITCJRETJVP 

RUNNINGJVPJ ID  .  01 

PROC# 1 .  INITIAL  ENTRY  INTO  CLUTTER  SUPPRESSION 


PROC# 1 .  WAIT  FOR  DATA  READY 


ENTERING  AWAIT 

ENTERING  ITCJRETJVP 

RUNNINGJVPJ ID  »  01 

ENTERING  TCJLOCATEJEVC 
ENTERING  TCJ SCHEDULER 
ENTERING  ITCJRETJVP 

RUNNINGJVPJ ID  ■  01 

ENTERING  ITCJLOADJVP 
ENTERING  ITCJRETJVP 

RUNNINGJVPJ ID  -  01 

LOADING  VP  NUMBER:  01 

PRIORITY  FOR  THIS  VP  IS:  40 
NEW  DBR  FOR  THIS  VP  IS:  0600 
ENTERING  GETWORK 

SELECTED JDBR  ■  0600 

ENTERING  RUNTHISVP 
SET  VP  TO  RUNNING:  VP  ■  01 


PROC#  1 .  PERFORMING  CL’  TTER  SUPPRESSION  ON  FRAME:  01 


procCl.  advance  filter  design  eventcount 

ENTERING  ADVANCE 

ENTERING  TCJ LOCATE SEVC 
ENTERING  ITCJRETJVP 

RUNNING* VP$ ID  «  01 

ENTERING  TC* SCHEDULER 
ENTERING  ITCJRETJVP 

RUNNING J VPS  ID  *  01 

ENTERING  ITCJLOADJVP 
ENTERING  ITCJRETJVP 

RUNNING JVPJ ID  *  01 

LOADING  VP  NUMBER:  01 

PRIORITY  FOR  THIS  VP  IS:  40 
NEW  DBR  FOR  THIS  VP  IS:  0600 
ENTERING  GETWDRX 

S ELECTED JDBR  »  0600 

ENTERING  RUNTHISVP 
SET  VP  TO  RUNNING:  VP  «  01 

PROC# 1 .  WAIT  FOR  DATA  READY 


ENTERING  AWAIT 

ENTERING  ITCJRETJVP 

RUNNINGJVPJID  -  01 


ENTERING  TCJLOCATESEVC 
ENTERING  TCJ  SCHEDULER 
ENTERING  ITCJRETJVP 


RUNNINGJVPJID  * 

01 

ENTERING  ITCJLOADJVP 
ENTERING  ITCJRETJVP 

RUNNINGJVPJID  - 

01 

LOADING  VP  NUMBER: 

01 

PRIORITY  FOR  THIS  VP  IS: 

41 

NEW  DBR  FOR  THIS  VP  IS: 

0700 

ENTERING  GETWDRX 

S  ELECTED  JDBR  * 

07  00 

ENTERING  RUNTHISVP 

SET  VP  TO  RUNNING:  VP  « 

01 

ENTERING  UNLOCXVTM 
ENTERING  CHECXPREEMPT 
ENTERING  ITCJRETJVP 

RUNNINGJVPJID  • 

01 

PROC*Z.  INITIAL  ENTRY  INTO  FILTER  DESICW 


PROC# 2 .  AWAIT  FOR  DATA  READY 


ENTERING  AWAIT 

ENTERING  ITCJRETJVP 

RUNNINGJVPJID  »  01 

ENTERING  TCJLOCATEJEVC 
ENTERING  TCJSCHEDULSl 
ENTERING  ITCJRETJVP 

RUNNINGJVPJID  »  01 

ENTERING  ITCJLOADJVP 
ENTERING  ITCJRETJVP 

RUNNINGJVPJID  •  01 

LOADING  VP  NUMBER:  01 

PRIORITY  FOR  THIS  VP  IS:  41 
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MEW  DBR  FOR  THIS  VP  IS:  0700 


ENTERING  GETTORK 

SELECTED  SDBR  «  0700 

ENTERING  RUNTHISVP 
SET  VP  TO  RUNNING:  VP  *  01 

PROC4Z .  PERFORMING  FILTER  DESIGN  ON  FRAME:  01 


PROC4Z.  ADVANCE  CLUTTER  SUPPRESSION  EVENTCOUNT 


ENTERING  A  D  V  A  N  C  E 

ENTERING  TCSLOCATESEVC 
ENTERING  I  TOSS  ENDS  PREEMPT 
ENTERING  I TCS SENDS PREEMPT 
ENTERING  ITCSRETSVP 

RUNNINGS VPS  ID  *  01 

ENTERING  TCS  SCHEDULER 
ENTERING  ITCSRETSVP 

RUNNINGSVPS ID  »  01 

ENTERING  ITCSLOADSVP 
ENTERING  ITCSRETSVP 

RUNNINGSVPS  ID  »'  01 
LOADING  VP  NUMBER:  01 

PRIORITY1  FOR  THIS  VP  IS:  40 
NEW  DBR  FOR  THIS  VP  IS:  0600 
ENTERING  GETTORK 

SELECTED SDBR  »  0600 

ENTERING  RUNTHISVP 
SET  VP  TO  RUNNING:  VP  »  01 

PROC#l.  PERFORMING  CLUTTER  SUPPRESSION  ON  FRAME:  0Z 


PROC#l.  ADVANCE  FILTER  DESIGN  EVENTCOUNT 


ENTERING  ADVANCE 

ENTERING  TCSLOCATESEVC 
ENTERING  ITCSRETSVP 

RUNNINGS VPS ID  -  01 

ENTERING  TCSSCHEDULER 
ENTERING  ITCSRETSVP 

RUNNINGSVPS ID  •  01 

ENTERING  ITCSLOADSVP 
ENTERING  ITCSRETSVP 

RDNNINGSVPSID  •  01 

LOADING  VP  NUMBER:  01 

PRIORITY  FOR  THIS  VP  IS:  40 
NEW  DBR  FOR  THIS  VP  IS:  0600 
ENTERING  GETTORK 

SELECTED SDBR  ■  0600 

ENTERING  RUNTHISVP 
SET  VP  TO  RUNNING:  VP  -  01  - 

PROC41.  WAIT  FOR  DATA  READY 


ENTERING  AWAIT 

ENTERING  ITCSRETSVP 

RUNNINGSVPS  ID  *  01 

ENTERING  TCSLOCATESEVC 


242 


OTTERING  ITCSSCHEDULER 

ENTERING  ITCSRETSVP 

RUNNINGS  VPS  ID  *  01 

ENTERING  ITCSLOADSVP 
ENTERING  ITCSRETSVP 

RUNNINGSVPSID  *  01 

LOADING  VP  NUMBER:  01 

PRIORITY  FOR  THIS  VP  IS:  41 
NEW  DBR  FOR  THIS  VP  IS:  0700 
ENTERING  GETTORK 

S ELECTED SDBR  *  0700 

ENTERING  KUNTHISVP 
SET  VP  TO  RUNNING:  VP  *  01 

PROC42 .  AWAIT  FOR  DATA  READY 


ENTERING  .  AWAIT 

ENTERING  ITCSRETSVP 

RUNNINGSVPSID  -  01 

ENTERING  TCSLOCATESEVC 
ENTERING  TCS SCHEDULER 
ENTERING  ITCSRETSVP 

RUNNINGSVPSID  -  01 

ENTERING  ITCSLOADSVP 
ENTERING  ITCSRETSVP 

RUNNINGSVPSID  -  01 

LOADING  VP  NUMBER:  01 

PRIORITY  FOR  THIS  VP  IS:  41 
NEW  DBR  FOR  THIS  VP  IS:  0700 
ENTERING  GETWORK 

SELECTED SDBR  «  0700 

ENTERING  RUNTHI SVP 
SET  VP  TO  RUNNING:  VP  »  01 

PROC42.  PERFORMING  FILTER  DESIGN  CN  FRAME:  02 


PROC42 .  ADVANCE  CLUTTER  SUPPRESSION  EVENTCOUNT 


ENTERING  ADVANCE 

ENTERING  TCSLOCATESEVC 
ENTERING  ITCSSENDSPREEMPT 
ENTERING  ITCSSENDSPREIMPT 
ENTERING  ITCSRETSVP 

RUNNINGSVPSID  »  01 

ENTERING  TCS SCHEDULER 
ENTERING  ITCSRETSVP 

RUNNINGSVPSID  ■  01 

ENTERING  ITCSLOADSVP 
ENTERING  ITCSRETSVP 

RUNNINGSVPSID  «  01 

LOADING  VP  NUMBER:  01 

PRIORITY  FOR  THIS  VP  IS:  40 
NEW  DBR  FOR  THIS  VP  IS:  0600 
ENTERING  GETWORK 

SELECTED SDBR  *  0600 

ENTERING  RUNTHI SVP 
SET  VP  TO  RUNNING:  VP  .  01 

PROCA1.  PERFORMING  CLUTTER  SUPPRESSION  ON  FRAME:  03 
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EXAMPLE  #4 


This  example  was  designed  and  implemented  by  Kurt 
Holmquist  for  testing  purposes  of  the  operating  system, 
and  consist  of  five  processes  running  on  a  uniprocessor 
system  under  the  operating  system. 

In  the  following  pages  are  included  the  input  source 
code  under  the  header  EXAMPLE  #4  INPUT  and  the  output  of 
the  microcomputer  directly  to  the  printer  under  the  header 
EXAMPLE  #4  OUTPUT. 
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EXAMPLE  #4  INPUT 

i 

;*  Tils  iaiul?  -cital-.s  j  prjcrsi  frao  aiiai 
T 1  *. : a  1  e  *-C-'«sses  ' a »  a  e  .-^aerate!  K / 

*->  D/  3  syoanronliatiaa  an-1  sa  nelul 1  a? 

:  a-.a'-ians .  Tie  auacer  of  jroiessss^ 
to  le  areatei  is  me  value  nuT_arca". 

>.?  araaesses  siauli  all  a?  la  tie  ’real/" 
s  t  a  te  ial tlai iy  .  »/ 

■r;-::  _prtc  :  :o: 

i’*“**a  External  praaeiur?  ieaiaratlons  ■;»»***/ 

ier:  P^DCEDTPE  'value-.  ETTF?  N AL ! 

DECLARE  value  WORE; 

i  : ; 

Ae»i_aaar:  PROCEDURE  BTTE  EXTERNAL, • 

2.  J 1  *  « 

mssaee:  3°o:ED’J?E  (fresv  ail)  EXTERNAL ; 

D  EC  LA®  E  nes?_ali  POINTER! 


Await:  30CCSDU0S  (event_naeie,aount)  EXTERNAL; 
DECLARE  ’vent_aan«  POINTER, 
aauat"*  WORE; 

End; 

*ivar-“:  PROCEDURE  (event  nine)  EXTERNAL! 
DEODARS  ev-at  lane  POfNTIR 1 


/**•**<>*  Event  aount  isalaratlaa  »**•**/ 


zizi^i 

a 

» 

if 

0 

ri 

* 

T< 

.next  (3)  BTTE  OitA  { 

'ADnxTi'); 

/  $  snu?  # v 

V) 

=>ssa?» 

ar.l  variable  lealaratloas  *«■****/ 

D  SC  LA?  E 

-_prrj?! 

<*' 

INITIAL  ( ?DHt0AE,0AH, 

'RUNNING  PROCESS  »'). 

(»' 

BITS 

INITIAL  ('3  DBR  -  ' 

,3)  , 

;  *  1 

PTTE 

INITIAL  ( (?EE,  0A  H ,  ' 

HIT  A  SET  TO 

CALL  ’ADTANCE".  '  ,lt )  . 

(*; 

3TTE 

INITIAL  (3D3.3A3,  ' 

SIT  A  SET  TO 

CALL  'AWAIT* . ',3) , 

(ewiltei  aauat,  ss  rev,  oroaess)  WORD, 

1  *'Cr.E  INITIAL  (i3>7  aaar  BTTE! 

DECLARE  aun_praa  LITER ALLT  'S'; 

DECLARE  ENTRT  LAPEL  RTSLIC! 

/*  Fravraa  far  aay  mnber  af  processes  to  execute  */ 
ENTP.T:  DO  WHILE  l; 

/*  Eaai  pro-ess  lieatlfles  Itself  87  resllae  tie 

value  of  tae  staale  sevvent  refister  (DPR).  */ 

S5_re?  »  ETACITASEf 

craaess  *  5".“(ss_rev,  t AND  3F3; 

anus  f?l  *  LOW  (proness)  -  3303; 


i 


i 


! 


I 


••  *  Print  cut  :aa  :uri;r  of  tne  proems  current iy 

runnlneaaitieC*?. .  */ 

CALL  "•«'!?»  !>  prun): 

CALL  Cu tcut_aer  Tss_r?r); 

CALL  ’'essave  ( A”_ai va : ; 

:n»r  =  /*  Js*  teyboari  input  to  step 

tnrouga  tne  proem-.  **/ 

-  ‘  3ecius=  tne  last  process  os  tne  ioal  list  aas  lower 

priority  taar.  all  ts?  ataers,  it  aas  a  silently  iiffereat 
pram”  seiuesce.  Tor  tne  last  process  oal/,  tne  process 
swttaa  will  taite  place  waei  tas  call  to  Aivaace  Is  naie.  */ 

IJ  process  »  oun_prae  THEN  20; 

CALL  Aivaace  Oaivaace_aexi )» 

END; 

/*  All  processes  except  tas  last  aae  oa  tas  loal  list 

execute  tie  followine.  */ 

ILSE  co; 

/*  Aivaace  tne  event  count  */ 

CALL  Alvance  Oaivance_aext ) ; 

CALL  “essage  (3!r_awai)i 

er.ar  *  R«si_cnar; 

swai tel_couat  »  ((1-1J/5  ♦  l'*5> 

CALL  Await  ( jalv»ace_next ,awal tel_couat } ; 

/*  Ctie  currently  runalnv  process  will  beccue  blockei 
at  tals  point  aoi  aaotoer  proces  will  beeia  ruaalag. 

«aea  a  process  vatca  aas  previously  blocxel  itself 
bsetrs  ruentn?  again,  tbs  entry  polr.t  will  be  here 
anl  tae  followlo*  call  will  ieternlae  tne'  process 
switcc  tl”e.  */ 

tN  u  ; 

Inc  ; 

s:iD? 
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EXAMPLE  #4  OUTPUT 


RUNNING 

PROCESS 

#1 

DBR 

a 

0710 

HIT 

A 

KEY 

TO 

CALL 

"ADVANCE* 

HIT 

A 

KEY 

TO 

CALL 

"AWAIT"  . 

RUNNING 

PROCESS 

*z 

DBR 

a 

0720 

HIT 

A 

KEY 

TO 

CALL 

"ADVANCE" 

HIT 

A 

KEY 

TO 

CALL 

"AWAIT* . 

RUNNING 

PROCESS 

43 

DBR 

= 

0730 

HIT 

A 

KEY 

TO 

CALL 

"ADVANCE* 

HIT 

A 

KEY 

TO 

CALL 

"AWAIT* . 

RUNNING 

PROCESS 

*4 

DBR 

X 

0740 

HIT 

A 

KEY 

TO 

CALL 

"ADVANCE* 

HIT 

A 

KEY 

TO 

CALL 

"AWAIT* . 

RUNNING 

PROCESS 

#5 

DBR 

a 

0750 

HIT 

A 

KEY 

TO 

CALL 

"ADVANCE" 

RUNNING 

PROCESS 

#1 

DBR 

X 

0710 

HIT 

A 

KEY 

TO 

CALL 

"ADVANCE* 

HIT 

A 

KEY 

TO 

CALL 

"AWAIT" . 

RUNNING 

PROCESS 

*2 

DBR 

3 

0720 

HIT 

A 

KEY 

TO 

CALL 

■ADVANCE* 

HIT 

A 

KEY 

TO 

CALL 

’AWAIT* . 

RUNNING 

PROCESS 

♦  3 

DBR 

X 

0730 

HIT 

A 

KEY 

TO 

CALL 

■ADVANCE" 

HIT 

A 

KEY 

TO 

CALL 

"AWAIT" . 

RUNNING 

PROCESS 

*4 

DBR 

X 

0740 

HIT 

A 

KEY 

TO 

CALL 

■advance* 

HIT 

A 

KEY 

TO 

CALL 

•AWAIT* . 

RUNNING 

PROCESS 

♦  5 

DBR 

3 

0750 

HIT 

A 

KEY 

TO 

CALL 

•advance* 

RUNNING 

PROCESS 

»1 

DBR 

3 

0710 

HIT 

A 

KEY 

TO 

CALL 

■advance* 

HIT 

A 

KEY 

TO 

CALL 

•AWAIT* . 

RUNNING 

PROCESS 

#2 

DBR 

a 

0720 

HIT 

A 

KEY 

TO 

CALL 

•ADVANCE* 

HIT 

A 

KEY 

TO 

CALL 

•AWAIT* . 

RUNNING 

PROCESS 

#3 

DBR 

a 

0730 

HIT 

A 

KEY 

TO 

CALL 

•ADVANCE* 

HIT 

A 

KEY 

TO 

CAU. 

•AWAIT*  . 

RUNNING 

PROCESS 

44 

DBR 

a 

0740 

HIT 

A 

KEY 

TO 

CALL 

•advance* 

HIT 

A 

KEY 

TO 

CALL 

"AWAIT* . 

RUNNING 

PROCESS 

♦  5 

D3R 

a 

0750 

HIT 

A 

KEY 

TO 

CALL 

"ADVANCE* 
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EXAMPLE  #5 


This  example  was  designed  and  implemented  by  the  following 
students  of  Naval  Postgraduate  School: 

LT  Kenneth  Webb 

LCDR  Leo  Schnieder 

LT  Antony  Christian 

in  partial  fullfillment  (as  a  project)  of  the  requirements  of 
the  course  CS  3550.  It  can  be  used  to  test  the  synchronization 
and  communication  mechanisms  of  the  operating  system. 

In  Figure  56  is  shown  the  interactions  of  five  processes: 
I/O  CONTROLLER,  ID-POSIT,  CORRELATION,  TRACK  and  DISPLAY.  Also 
shown  are  five  shared  buffers:  SENSBF ,  SENSDR,  ACTIVE-BUFFER, 
OUTPUT  TABLE  and  TRACK  TABLE  residing  in  the  system's  global 
memory  while  the  processes  code  and  data  are  located  into  the 
microcomputer's  local  (on  board)  memory.  For  example,  the 
shared  buffer  SENSBF  is  used  by  the  I/O  CONTROLLER  and  ID-POSIT 
processes:  and  so  on. 

Flow  of  information  into  and  out  of  the  various  processes 
and  buffers  is  indicated  in  Figure  56  by  the  direction  of  the 
arrows.  Eventcounts  are  shown  between  the  processes. 

The  details  about  this  project  will  not  be  incorporated 
here  since  these  can  be  extracted  from  the  following  input 
source  code,  under  the  header  EXAMPLE  #5  INPUT.  The  output 
to  the  printer  follows  the  input  source  code,  under  the 
header  EXAMPLE  #5  OUTPUT. 
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EXAMPLE  #5  INPUT 


:?3Sir:io;  -  ■— ■ 

,  MODULI  BEGINNING*/ 


/*  declarations*/ 

OZCLAPZ  »  /CP.D  IIITTALU)! 

DECLARE  '5)  LITE  DATA  ('IE???*'); 

LiDLARE  :iP3«  (6)  3m  DATA  ('IDPOS?')! 

DECLARE  IDP*2  '2)  3332  DATA  ('IDPREi')! 

declare  :gtsd»ta(=)  3m  cat  a  (  'tgtsdatak'); 

CELLARS  IDS?r>3 1?$START( 15)  BTTS  DATA( 'ID$POSIT$STAR IS' } ! 
DECLARE  I  INTEGER  INITIAL  (0); 

LEGLARE  SENSED?  (22)  STR3CTJRE  ( INFO  ( 15)  Utl,  TTKE  (fORt , 
PLAGS7  3TTE!  EXTERNAL! 

DECLARE  RESET  LITERALLT  '3PS  '  i 
DECLARE  22  .ORE  Initial  (1); 

3EDLAPZ  (J.L.I.3SAPIN3)  INTEGER! 

DECLARE  (XSSENS,  T5SENS,  RANGE)  INTEGER! 

DECLARE  SOFTER ( 12)  INTEGER! 

CECLAPE  (3NG5NULTSPTP,  PPSITJPTP)  ROINTEP! 

DECLARE  SENSSNtJNl  INTEGER  EXTERNAL! 

DECLARE  (XSTGT,  TJTGT)  INTEGER  EXTERNAL! 

CECLAPS  rr-El  »C?.D  EXTERNAL! 

CECLARE  (RNG5T7LT  RASED  BNGJflOLrsPTR )  (2)  INTEGER! 

DECLARE  (POSIT  RASED  POSITSPTR ) <2 )  INTEGER! 


AAA.  IT  :  PS3CSDDPE  ( E7CS IDSPARW,  S7C$TAL$PAR'1)  EXTERNAL! 
DECLARE  EVCSIDSPARf*  POINTER! 

DECLARE  E7CS7ALSPAPM  <CRD! 

END  ARA IT! 


ADVANCE:  PROCEDURE  ( ZVCS ID$P AR* )  EXTERNAL! 

LECLARE  EVCSIDSPAR-  POINTER! 

END  ADVANCE! 

3NGANALTZSP :  PPOCJDORE  (BEARING)  POINTER  EXTERNAL! 

DECLARE  EEARING  INTEGER! 

END  3NGANALTZER! 

TG?$?CS IT:  PROCEDURS  (XSBA5E,  TJ3ASE,  XSCOIP,  TSCOMP,  PNG)  POINTER 
EXTERNAL! 

DECLARE  ( X>8ASE, TJBA3E,  XSCOHP,  TJCOMP,  RNG )  INTEGER! 

END  TGTS POSIT! 


*rlte:  protelars  (ptr)  external! 
lenlareetr  pointer! 

•nl ; 


:n::v2;  proceeors  external; 
end; 


/•END  3?  THE  DECLARATIONS*/ 


CALL  INIT72! 
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:c  on*  ?i; 

a’-L  UHT  (3IIPRE.ZE): 

zz  -  zz  *  1; 

:•  5INS5UF( I ) .  FLAGS  7  *  31R  TEEN 

/•INCRE-ENT  TEE  BUFFER  COUNT  AND  DETAIN  T3E  DATA.  CCN7ERT 
"RDM  ASCII  TD  .NUMEP.IC*L  REPRESENTATION.*/ 

I?  I  <  22  TEEN 

oc; 

ZD  J  =  0  TO  14, 

BUFFERS)  •  INT(SENSBUF(I) .INFO(J)  -  30H); 
END; 

enz; 

ELSE  to; 

i  *  a; 

ZD  C  =  0  TO  14,* 

BUFFER! J )  •  INT(  SSNSBUF(I) .INFO(J)  -  30H) 

end; 

end; 

zd; 

SENSSUF(I) .FLAGS?  -  RESET i 

i  -  :  *  i; 

end; 


/*  THE  NEXT  STEP  IS  TO  C0N30IIDATS  THE  INPUT  INFORMATION 
INTO  THE  APPROPRIATE  VARIABLES*/ 


do; 

TSSENS  - 


TSSENS  * 


3EARING  - 


°1NGE  » 


end; 


((1000  •  BUFFER(l))  - 
(100  *  BUFFER (2))  * 
(10  *  BUFFERS))  * 
(BUFFER (4) ) ) ; 

(Ue00  *  BUFFER ( 5 ) )  * 
(100  *  BUFFER (6) )  * 
(10  *  BUFFER  (7d  * 

( BUFFER (S) ) ); 

((100  *  BUFFSRO) )  ♦ 
(10  •  BUFFER! 10) )  - 
(BUFFER (11 ) ) ) ; 

((103  *  BUFFER ( 12 ) )  ♦ 
(10  *  BUFFEH(13) )  * 

( BUFFER (14) )  ) ; 


/*  CALL  THE  SUBROUTINES  0RICH  ANALTZI  THE  DATA  TO  PRODUCE 
THE  TARGET'S  POSITION  ON  AN  X-T  GRID*/ 

do  ; 

:ill  writ?  (.>('C«lliag  Bs*rlny_*a*llitr.l') ) ; 

:all  write  (J('C«lUi?  target  posit. *'))» 
end; 


/«  LOAD  THE  “E-ORT  SHARED  0ITH  THE  CORRELATION  PROCESS*/ 

CALL  A/AITOTDBUF.N) ! 
i  -  *  ♦  u 

0?  t 

SENSSN'Tf'l  «  ;c?TTR(0d 
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correlation:  ro ;  /*  pectining  o?  -odulz  *' 

/*  this  -cd'-lz  detep-ines  ^HErni?.  km  inc3-Ii<g  targets  c»n  -i 
odrjziatzi  pith  ant  tracks  alreatt  being  tracked  in  the 
TR'CiST‘ELr .  ir  these  is  a  correlation  .THEN  THE  MODULE 

JPDATES  THE  TARGET'S  X  POSITION,  r  POSITION,  ANC  TIME. 

:r  TEEPE  IS  NO  CORRELATION .THIN  TEE  -COOLS  ASSIGNS  T=Z 
N £4  TARGET  A  Mi  TRACE  NU-BER  AN 0  ENTEPS  IT'S  TRACE 
NJ-SER,  X  POSITION,  T  POSITION,  ANT  TI-E  IN  TEE  TRACKS 
T*3LE.  */ 


/*  FXTSRNAL  DECLARATIONS  •/ 

DECLARE  TRACIJTAFLE ( 25 ) STRUCTURE ( TRACK SNR  rfORD  ,X*POSI?  INTEOEa, 
T5POSIT  INTEGER, TTTE  WRD.CSE  INTS3SP  ,5?D  INTEGER, 
XSEtIPOS  INTEGER  ,TS?UPOS  .INTEGER )  EXTERNAL ; 

LECLARE  ACTITESB3FF  STRUCTURE ( TRACKJNR  RORD,X$POSIT  INTEGER, 

tsposit  integer , itme  <ord) external; 

DECLARE  SENS$Na-l  INTEGER  EXTERNAL? 

DECLARE  ( •’STGT.rsTGT)  INTEGER  EXTERNAL? 

LECLARE  TX-E1  NORD  EXTERNAL; 

/*  INTERNAL  DECLARATIONS  */ 

DECLARE  (N.J.TFOUND)  oat; 

DECLARE  Z  *ORE; 

DECLARE  4  40RU  INITIALS)? 

DECLARE  f.  iORD  INITIAL(a); 

DECLARE  ( TPU3, FALSE )  RCRD  INITUL(0FFS,00H) ! 

DECLARE  IDPOS (6) BTTE  DATA!  '  ICPOS?  ' )  ? 

DECLARE  AC3'J7(S)  ETTE  DAT  A(  'ACBUF?'  ) ? 

DEC  LA°E  I03U?(5)?TTE  DATA (  'IDBUF? ' )  i 
DECLARE  ?• F AC(5 ) PTTE  DATA (  'TABAC?  '  ?  ? 

DECLARE  ( SENSOR, XT AR.rTAR) INTEGER; 

CSCLAPE  Ths  *CPD; 

DECLARE  MSG1 ( *) BTTE  INITIAL! 'ENTERING  CORRELATION?  ' ) ; 

LECLARE  MSG2( • ) BITE  INITIAL! 'LEAVING  CORRELATION?'); 

/*  EXTERNAL  PROCEDURES  •/ 

/•  THE  ADVANCE  MODULE  AD7ANCES  THE  VALUE  OF  EVC*  ID*PA?.M.  V 

ADVANCE:  PROCIIUHI(EVC?ID»PAR!1)  EXTERNAL; 

DECLARE  IVC?ID$PARN  POINTER; 

END  advance; 

/•  THE  AR AIT  -OLULE  flLL  BLOCK  THE  CALLING  PROGRAM  FROM 
EXECUTION  UNTIL  EVC* ID*PARM»I7CS7AL*PARM  .  V 

AWAIT :  PROCEDURE  (EVC*  IDmRM,lVC*VAL*PABM)  EXTERNAL; 

DECLARE  EVC* IDIPARN  POINTER; 

DECLARE  EVC*VAL*PARrt  <ORD? 

END  AWAIT! 

/*  THE  TMATCH  MODULE  DETERMINES  JfRETRlP.  THE  INCOr.ING  TARGET'S 
X  PCS ITICN  CORRELATES  WITH  ANT  FUTURE  X  POSITIONS  DP  TRACTS 
THAT  ARE  ALREADT  IN  THE  TRACIJTABLE.  _  */ 

XMATCH:  PROCEDURE! TABLE* PTR  ,  XTAR  ,N ) #0?.D  EXTERNAL? 
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CECLAFE  "ABJ.ES  PTE  ?3l:.T2’J 

declape  cap.  inteoer; 

DFCLiFE  'I  *obd; 

•vc  x.hatce; 

THE  THATCH  "OE'JLZ  COMPARFS  THE  T  FUTURE  POSITION  OF  THE  TRACK 
SOUND  In  "HATCH  “OCTL t  TO  THE  rNCDHINO  Ta.RCE '  '3  I  POSITION 
AM  LITER-INSS  IF  THERE  IS  A  CORRELATION.  *, 

T-ATCH:  ?BDC£DORE( FOTUPEr.TTARjFORC  EXTERNAL; 

DECLARE  FUTURE!  INIESEP.; 

oeclape  ttaf.  intecep; 
end  thatch; 

THE  TA RLE  "ODULE  FILLS  THE  T3ACXSTA3LE  FITH  TRACE  '10H9ER  , 

:<  POSITION,  r  POSITION.  AND  TIT'S  OF  ALL  NEF  TRACES.  */ 

TA3LE :  ?  R  OCEItJR  £(  “,.K  T  AR,  IT  A  R.T)  EXTERNAL; 

DECLARE  H  FORD; 

DECLARE  (XTAR.ITAR) INTIOSR; 

DECLARE  T  FORD; 

END  TABLE! 

THE  PUFF  “ODULE  UPDATES  THE  ACTIVZ52CFF  FITS  TRACE  NUMBER , 

X  POSITION,  r  POSITION.  ANE  TI"E  OE  ALL  OLD  TRACKS .  V 

BUFF:  PROCEfJRE(  TN.  CAR,  r?A8,T)  EXTERNAL,* 

DECLARE  (TN.T)FORD; 

DECLARE  (XTAR.ITAR)INIEOER; 

END  30FP; 

THE  FRITS  "CHILE  IS  USED  TO  PRINT  DOT  HESS  ACES .  V 

FRITS:  P'’OCEDOR£(PTR)SXrSRNAl; 

DECLARE  PTR  POINTER; 

END  FRITE; 


/*  HAIN  PPOSRAH  */ 


CALL  FRITEO*SCl)5 
CALL  AW Al T( 3IDP0S « Z )  » 

SENSOR-SENSSNOfi; 

xtap-xstot; 

ITAR»T>TCT; 

T'1I«TT'*Si; 

CALL  ADTANCI{3IDB0i); 

CALL  AWAITOTA3AC.F); 
t700nd-fai.se; 

j-i; 

n-j; 

CO  FEILE  JK25  AND  "FOUND-FALSE! 


C«XMATCH( 3TRAC5$T13L2,XTAR,N); 


i 

4 

! 
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CELLARS  SET  LITERALLI  'cl?.', 

G'JTS TA5LSSPT?  POINTER. 

ESLIMITER  LITER ALL!  '2fd'; 
i!;lar*"J?DAT  f3)  SITS  DATA  l '  JPDATi') . 
OTRLT  '.S'  SITE  OAT  A  t  'OTRCTX  * ) , 
a:buf  (3)  byts  lata  ('abbuft'). 
taos:  (5!  byts  lata  ('tabasi'), 

4  ori  liitlal  (3), 

1  ori  111 tlal  ( 2 ) , 
ar.trv  a  las*l  tuoli;, 

J  ori  i-.ltiai'  (!': 


CECLARE  SOFT  (4)  3TRaCT7?.E  (TRACXSNH  iORD ,  XSPOSIT  INTEGER. 
ISPOSIT  INTEGER.  TIME  INTEGER.  OSS  INTEGER, 

3PL  INTEGER,  FLAG  SITE )  I 

CELLARS  3C7PUT5TA3LE  STROCTORE  (TRACTSNP  <IORD,  XSPOSIT 
INTEGER.  ISPOSIT  INTEGER.  TIME  INTEGER, 

03 E  INTEGER,  3PD  INTEGER,  PLAG  SITE) 

external; 


rfRITE:  PROCEURE  ( PTR)  EXTERNAL; 

OECLARI  PTR  pointer; 
snc  ; 

ADTANOi:  P’OCECURE  (  E7C$  IDSPAR'I )  EXTERNAL.- 
CECLARE  ETCSIDSPAHM  POINTER; 

ENL  actance; 

A^ AIT :  PROCEDURE  (  ETCS  IDSPAR'I,  STCSTALSPARM)  EXTERNAL; 
CEOLARE  iVCSIISPARM  POINTES, 

I7L  S  7  ALS  ?  A0-1  iO ROi 


»3try  a: 

OALL  JRITS  ( 3 ( 'BEGIN  TEST  OF  DISPLAT.X  ')); 


/*  INITIALIZE  V 

3DFF(1 ) . TRACISNR  -  i; 
5JFF(1 ). XSPOSIT  *  331 ; 
3DFF<1). ISPOSIT  -  103*; 
9C?F(1 ) .TIME  *  13*; 
5DFF(  1 ) .CSE  -  2*0! 

3  JFF I 1 ) . 3PL  -  3*3! 

3DFF( 1 ) . FLAG  *  SET; 

BDFF(3). TRACISNR  «  13! 
EJFF(3). XSPOSIT  -  212, - 
3CJFF (  3  )  .TSPOS IT  »  2*13, - 
BD7F(3 ) .TIMI  *  24S; 
93FF(3).GSE  «  153! 
3U?F(3).3?D  •  1300; 
BtJFFf?) .FLAG  =  SET; 


t 
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:o  <an»  ii; 

rill  iwiit  Oar'ruf.  w); 

*  =  f  -  i ; 

rail  writs  0\  'Ixtractlae  lati  f ran  a  iuffsr  siarsi  wlta  C3?.3i..ATE . 
ilTir.r;  (  3ta  ra?  '  i 


CALL  AWAIT  03T5ET.  I); 

CUTPUTSTABIS. TRACTS NP  »  30FF(  J)  .TPACTSNP.5 
:JTP5TSTA3U.TS?0SIT  »  3U?;(J).VSP3SIT; 
CjTPUTsTABLS.TS POSIT  »  BUFF { J 1 . TSP03 IT; 
jJTPCTST ABLE. CITE  -  BU??( J I  .TI-EI 
OJTPJTjTABLZ.CSE  «  3  JFF( J ) .C3E  i 
O'JTP'JTsTABLS.SPD  *  BUFF ' J ) .3  PD J 
OUTPUT^TAECE.EtAG  -  30TT(S) .ELAC! 

1-1*1.; 

CALL  W? I ISO l  'BUFFER  FILLED.  ADVANCING  DISPLAT.i  ))! 

CALL  ADVANCE  OffPDAT) « 

END! 


It.'!:  r 3 ; 


‘G7*  NGS:  PROCEDURE  (  E7CS  IDSPAP.'* )  EXTERNAL? 

declare  etcsidspar?*  pointer; 
end; 

prociltre  <etc$i:spa.r'»,  •  7Cs7als?a?.“)  external; 
declare  evcsidspar?  pointer, 

E7C$7AL5PA?.'1  WORD?. 

1ST  ; 

•  PITS:  ’ROCSDCPS  (’TP!  EXTERNAL > 

CFCLARE  PTR  POINTER; 

enc; 


:0N7EPT$TA3LS:  °ROCEDURS  ( TABLESPTR )  POINTER  EXTERNAL? 
CECLAP.E  TABLESPTR  POINTER; 

end; 


DECLARE  I  WOP.O  INITIAL  (1). 

PTR  POINTER, 

0 jtstaelesptr  pointep, 

SET  LITERALLT  'ZIP'. 

RESET  LITERALLT  '028', 

DELIMITER  LITERALLT  '2SH'? 
ismrsJPtAr  (S)  SITE  LATA  ('OPDATS'), 

:i?:r  (5*  3TTS  DATA  l'OT"3T*'). 

(c.  i )  ptte; 

DECLARE  OCTPCTST A3LE  STROCT'JRE  ( TRACXSNR  WORE,  XSPOSIT  INTEOER, 
TSPOSIT  INTEGFR.  TIME  INTEOER,  CSE  INTEGER, 

5PT  INTEGER,  "LAG  3TTE)  EXTERNAL? 


OSCLA’E  LOCSBUES  STRUCTURE  (TRAGESNR  WORD,  TSPOSIT  INTEGER, 
TSPOSIT  INTEGER,  TIME  INTEGER,  GSE  INTEGER, 

3 PD  INTEGER,  FLAG  BTTE); 

OFCLAPE  (OCTSTA3LE  BASED  OUTSTA3LESPTR)  (25)  STRUCTURE  (TRESNP. 
(12)  BTTE,  XS3  (12)  3TTE, 

TS?  (12)  BTTE.  T  (10)  BTTE,  CSE  (12)  BTTE,  SPD 
(12)  BTTE,  IIIIT  BTTE); 


GALL  WRITS  Ot 'ENTERING  DI3PLA T.X ' ) > ? 


DO  *nlls  Si; 

GALL  AWAIT  OC’DAT.  II ; 

CALL  WRITE(0( 'ENTERING  GISPLAT  LOOP.S')!; 
i  -  i  *  i; 
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LCCSB'JEP.TPACESNS  -  outputs  table  .trace snp.  ; 
UCOSrJEs  .UP03I?  «  OUTPUTS  TABLE . IS P3SI T; 
Lc:$3ii?p.rs?r;:?  «  curpu?$TABLE.r?os:?; 

oocspu'r.ri'iE  =  outputs  r  a  ble.ti'ie; 

10CSEUEF.3SE  -  OUTPJTSTABLE.CSE; 
LOOSBUFF.SPD  *  OUTPOTSTABLE.SPO; 

L0CSF77?. ELA3  =  OUTPUTSTABLE  .JUG; 


/’*  convex:  tat a  :o  ascii  fox  ootpjt.  «/ 
outstiSljsrtr  *  'o:v?rtstibli  Oloisauf?) ; 


/*  iP.ITS  DATA  ON  CONSOLE .  */ 

C»LL  rfRITS  (l»(  'TXACt_NH  T_POSIT  T_?OSI?  TI1E  COURSE 

io  j  *  3  to  25! 

If  aut  5 1  s  bl?  ( J ) .  lei  1  n  =  ijll.ultir 
1 1 s 3  :jU  writ*  (  AoutStablsIj  ) ) ; 

;r.i  1 


CALL  AOVANCE  (BOTREr)} 


E.NO; 

•  no  ; is  plat: 


spEEtrn 
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EXAMPLE  #5  OUTPUT 


Entering  IDPOSIT  LOOP. 

ENTERING  AWAIT 

ENTERING  CORRELATION 

ENTERING  AWAIT 

BEGIN  TEST  OF  DISPLAY. 

ENTERING  AWAIT 

ENTERING  DISPLAY. 

ENTERING  AWAIT 

Entering  IDLE  PROCESS. 

Entering  IDLE  PROCESS. 

Entering  IDLE  PROCESS. 

Entering  IDLE  PROCESS. 

Entering  IDLE  PROCESS. 

CALL  ADVANCE (IDJPOS IT) . 

ENTERING  ADVANCE 

Calling  bear i ng_*nal i ter . 

Calling  t arge t_pos i t . 

ENTERING  AWAIT 

ENTERING  ADVANCE 
Entering  IDPOSIT  LOOP. 

ENTERING  AWAIT 

ENTERING  ADVANCE 

ENTERING  AWAIT 

ENTERING  ADVANCE 

LEAVING  CORRELATION 
ENTERING  CORRELATION 

ENTERING  AWAIT 

Extracting  data  from  a  buffer  shared  with  CORRELA 
ENTERING  ADVANCE 

OTTERING  AWAIT 

BUFFER  FILLED.  ADVANCING  DISPLAY. 

OTTERING  ADVANCE 


TE. 
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ENTERING 


A  W  A  I  T 


ENTERING  DISPLAY  LOOP. 


TRACK  NR 

X  POSIT 

Y  POSIT 

TIME 

COURSE 

00 

331 . 8 

678.9 

0067 

240 

01 

443 . 1 

444.4 

0175 

240 

ENTERING  ADVANCE 


ENTERING  AWAIT 

Entering  IDLE  PROCESS. 

Entering  IDLE  PROCESS. 

CALL  ADVANCE! IDJPOS IT) . 

ENTERING  ADVANCE 

Celling  beer ing_anal i ter . 

Celling  target_poa i t . 

ENTERING  AWAIT 

ENTERING  ADVANCE 
Entering  IDPOSIT  LOOP. 

ENTERING  AWAIT 

ENTERING  ADVANCE 

ENTERING  AWAIT 

ENTERING  ADVANCE 

LEAVING  CORRELATION 
ENTERING  CORRELATION 

ENTERING  AWAIT 

Extracting  date  from  a  buffer  shared  with  CORRELA 
ENTERING  ADVANCE 


ENTERING  AWAIT 

BUFFER  FILLED.  ADVANCING  DISPLAY. 

ENTERING  ADVANCE 


ENTERING  AWAIT 
ENTERING  DISPLAY  LOOP. 


TRACK  NR 

X  POSIT 

Y  POSIT 

TIME 

COURSE 

00 

231.8 

678.9 

0067 

240 

01 

443.1 

444.4 

0107 

240 

ENTERING  ADVANCE 
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SPEED 

0345 

0345 


TE. 


SPEED 

0345 

0345 


ENTERING 


AWAIT 


Entering  IDLE  PROCESS. 

Entering  IDLE  PROCESS. 

Entering  IDLE  PROCESS. 
EnterinCALL  ADVANCE ( IDSPOS IT) . 

ENTERING  A  D  V  A  N  C  E 

Calling  bear i n g_ana 1 i z e r . 
Calling  t ar ge t _pos i t . 

ENTERING  AWAIT 


ENTERING  A  D  V  A  N  C  E 
Entering  IDPOSIT  LOOP. 

ENTERING  AWAIT 

ENTERING  ADVANCE 

ENTERING  AWAIT 

ENTERING  ADVANCE 

LEAVING  CORRELATION 
ENTERING  CORRELATION 

ENTERING  AWAIT 

Extracting  data  from  a  buffer  shared  with  CORRELA  TE. 
ENTERING  ADVANCE 


ENTERING  AWAIT 

BUFFER  FILLED.  ADVANCING  DISPLAY. 

ENTERING  ADVANCE 

ENTERING  AWAIT 


ENTERING  DISPLAY  LOOP. 


TRACK  NR 

X  POSIT 

Y  POSIT 

TIME 

COURSE 

SPEED 

00 

231 . 8 

678.9 

0067 

240 

0345 

01 

443 . 1 

444.4 

0107 

240 

0345 

02 

443 . 1 

444.4 

0006 

240 

0345 

ENTERING  ADVANCE 


ENTERING  AWAIT 


Entering  IDLE  PROCESS. 
Entering  IDLE  PROCESS. 
CALL  ADVANCE! IDSPOSIT) 
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ENTERING  ADVANCE 


Calling  bear i ng_ana 1 i :ei . 
Calling  target_pos i t • 

ENTERING  AWAIT 


ENTERING  ADVANCE 
Entering  IDPOSIT  LOOP. 
ENTERING  AWAIT 


ENTERING  ADVANCE 


ENTERING  AWAIT 


ENTERING  ADVANCE 

LEAVING  CORRELATION 
ENTERING  CORRELATION 

ENTERING  AWAIT 

Extracting  data  from  a  buffer  shared  »ith  CORRELA  TE. 
ENTERING  ADVANCE 


ENTERING  AWAIT 

BUFFER  FILLED.  ADVANCING  DISPLAY. 

ENTERING  ADVANCE 


ENTERING  AWAIT 


ENTERING  DISPLAY  LOOP. 


TRACK  NR 

X  POSIT 

Y  POSIT 

TIME 

COURSE 

SPEED 

00 

231.8 

678.9 

0067 

240 

0345 

01 

443. 1 

444.4 

0107 

240 

0345 

02 

443. 1 

444.4 

0006 

240 

0345 

03 

333.9 

335.2 

0175 

240 

0345 

ENTERING  ADVANCE 


ENTERING  AWAIT 

Entering  IDLE  PROCESS. 
Entering  IDLE  PROCESS. 
Entering  IDLE  PROCESS. 
Entering  IDLE  PROCESS. 
Entering  IDLE  PROCESS. 
Entering  IDLE  PROCESS. 
Entering  IDLE  PROCESS. 
CALL  ADVANCEt IDSPOSIT) . 

ENTERING  A  D  V  A  N  C  E 

Calling  bearing  analiser. 
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Calling  t ar ge t _po s i t . 
ENTERING  AWAIT 

ENTERING  ADVANCE 
Entering  IDPOSIT  LOOP. 
ENTERING  AWAIT 

ENTERING  ADVANCE 

ENTERING  AWAIT 


ENTERING  ADVANCE 

LEAVING  CORRELATION 
ENTERING  CORRELATION 

ENTERING  AWAIT 

Extracting  data  from  a  buffer  shared  with  CORRELA 
ENTERING  ADVANCE 


ENTERING  AWAIT 

BUFFER  FILLED.  ADVANCING  DISPLAY. 


ENTERING 

A  D  V  A  N 

C  E 

ENTERING 

A  W  A 

I  T 

ENTERING 

DISPLAY  LOOP. 

TRACK  NR 

X  POSIT 

Y  POSIT 

TIME 

COURSE 

00 

231.8 

678.9 

0067 

240 

01 

443 . 1 

444.4 

0107 

240 

02 

443.1 

444.4 

0006 

240 

03 

333.9 

335.2 

0175 

240 

04 

443 . 1 

444.4 

0242 

240 

ENTERING  ADVANCE 


ENTERING  AWAIT 


Eater ing 
En  t  e  r  i  n  g 
Eater ing 
En  taring 
Eater ing 


IDLE  PROCESS. 
IDLE  PROCESS. 
IDLE  PROCESS. 
IDLE  PROCESS. 
IDLE  PROCESS. 


TE. 


SPEED 

0345 

0345 

0345 

0345 

0345 
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EXAMPLE  #6 


This  is  the  last  and  more  powerfull  example.  Last 
because  no  time  is  left  for  more  testing  of  the  operating 
system.  Powerfull  because  PR0C01  is  loaded  to  one  physical 
processor  and  PR0C02  is  another  physical  processor.  These 
two  interactive  processes  use  the  synchronization  and 
communication  mechanism  and  also  the  hardware  interrupt 
structure  as  it  was  configured  to  provide  inter-real 
processor  communication  (to  support  the  preemptive  scheduling) . 
Furthermore  in  this  example  only  the  ITC  level  is  used  to 
demonstrate  the  verifiable  "loop  free"  structure  of  the 
operating  system  (the  TC  level  is  not  linked  with  the 
operating  ystem  in  this  specific  example) . 

These  two  processes  are  initialized  as  ITC  processes,  in 
the  same  way  as  they  initialized  the  MMGT  and  IDLE  process. 

For  their  interactions,  the  inter-virtual  processor 
synchronization  mechanism  is  used. 

The  address  space  descriptor  (the  base  of  the  stack)  for 
the  IDLE  process  is  5000,  for  the  MMGT  process  is  5500,  for 
the  first  process  is  6000  and  finally  for  the  second  process 
is  7000.  Four  VP's  are  used  per  real  processor. 

The  input  source  code  for  these  two  processes  is  under 
the  header  EXAMPLE  #6  INPUT. 
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Figure  57  illustrates  some  more  output  messages  incorporated 
in  new  modules  used  for  this  current  demonstration  of  the 
operating  system  (which  were  not  included  in  Figure  55). 

The  output  to  the  printer  is  included  under  the  header 
EXAMPLE  #6  OUTPUT  #1  for  the  first  mocrocomputer  and 
EXAMPLE  #6  OUTPUT #2  for  the  second  one. 

It  can  be  seen  from  OUTPUT  #2  that  when  the  PR0C#2  is 
waiting  the  occurrence  of  the  event  FLDES  (to  reach  a 
speciiied  value)  because  no  other  process  is  located  on  the 
physical  processor,  it  starts  executing  the  IDLE  process 
(it  outputs  repeatedly  the  message  ENTERING  UPDATECOUNTER) . 

When  this  specific  event  reaches  the  necessary  value  PROCtl 
signals  to  PR0C#2  (using  the  ADVANCE  operation)  the 
occurrence  of  this  event.  Since  PR0C#2  is  loaded  on  another 
physical  processor,  the  hardware  interrupt  structure  is  used 
to  awaken  this  process  (in  OUTPUT  #1  after  the  message 
ITC$ ADVANCE  there  is  the  message  ENTERING  HARDWARE  $ INT ) . 

After  receiving  this  signal,  the  physical  processor  exits 
the  IDLE  process  and  continues  on  the  previous  task  (PR0C#2) 
and  so  on. 

To  ensure  in  this  example  that  the  hardware  interrupt 
mechanism  will  be  invoked,  a  different  delay  is  used  in  these 
two  processes. 
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LEVEL 


MODULE _ 

ITC$INIT 
KERNELS INIT 
ITC$AWAIT 
ITC$ LOCATE $E VC 
ITC$ADVANCE 
GET$COUNTER 
UPDATE$COUNTER 
HARDWARE  $  If JT 


OUTPUT  MESSAGE _ 

ENTERING  ITC$INIT 
ENTERING  KERNEL$INIT 
ENTERING  ITC$AWAIT 
ENTERING  ITC$LOCATE$EVC 
ENTERING  ITC$ ADVANCE 
ENTERING  GETCOUNTER 
ENTERING  UPDATECOUNTER 
ENTERING  HARDWARE $INT 


FIGURE  57 


MORE  OUTPUT  MESSAGES 


EXAMPLE  #6  INPUT 


,*  TILE  PR0C21.SRC  15  <**r  */ 

CSJPPS'SOD'JLS:  DC! 

zizu.n  c.z)  ir-.z; 

ceclafe  cf  liter alli  so h  . 

LT  LITERA  LLT  '2Ar.'i 

declare  <  n?.r; 

zz:ik°z  :$”??  3rrr  data ( 3 3 ) ; 

CZCLAFZ  -LIES  FITE  iATA(44)! 


DECLA0  E 

''S3H*)  FITE  INITIAL  l  ?S0C*1 . 
*302!*)  SITE  INITIAL  (/PR0C*1. 
'•FIJI*)  SITE  INITIAL  l'?ROC*l. 
>-S:4(*)  3TTI  INITIAL  ('?R0C»1. 


INITIAL  t.NTST  I, NT 0  CLUTTER  SUPPRESSION' '  , 
WAIT  FOR  DATA  READ! 

PERFORMING  CLUTTER  SUPPRESS  ION :  FRAME  *  i. 
ADVANCE  FILTER  DESION  EVENTCOUN?  '); 


I "C S A* A IT1 :  ?bCCSDUPE(37CSID,AWAITED$?ALUE)  EXTERNAL! 
DECLARE  ZVC$ID  SITE, 

awaitsdsvaue  word; 
end; 


HCSAIVANCE:  PROCEDURE! ZVCS ID )  EXTERNAL! 
CSCLAPE  37CSID  3ITE! 

ENC! 


OUTSOHA5:  ?ROCEtURE(CHAR  )  ! 

DECLARE  CHAP  SITE! 

ZO  WHILE  ( INPUT! tfDAH)  AND  21H)  *  2!  END! 

OUTPUT  UD3H)  -  CHAR! 

END! 

UCTSHETs  PROCEDURE! ? ) ! 

DECLARE  P  SITE! 

DECLAPS  ASCII!*)  SITE  DATA  <  31E3455733ABCDEF’  )! 
CALL  OUTsCHAF ( *SCII(SHR(B,4)  AND  0:3))! 

CALL  CUTSCHAP.USCIIO  AND  3FH))! 

END! 

1*2! 


CO  Z  «  2  TO  45! 

CALL  OUTS CHAR! *531  ( Z ) ) » 

END! 

CALL  OUTSCHAR(CR) ! 

CALL  OUTSCHAR(LF)! 

DO  WHILE  (I  <•  2FFH ) ! 

LO  Z  *  2  TO  45! 

CALL  OUTSCHAR!  MS32 !Z ) )  / 

ENC! 

CALL  OUTSCHAP ! CR ) » 

CALL  OUTSCHAP! LF ) ! 

CALL  ITCJAW HTHCSCPP .  I )  • 

I  -  I  *  l!  /*  <— — —  */ 


■^-srrr 


\ 
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;o  7  -  ,*  ’o  17; 

c\ ll  :j:schas(',5:3(:)); 

Jmc; 

call  cccstim  n ; 

:u:  cjtjcha? ( c?. ) ; 
call  3u?scsap{lf'; 

:o  i  -  a  to  iac?; 

CALL  TL^El  2£«: )  ; 

in  r ; 

CC  7  =  3  TO  45; 

call  3jrsc:jA?.(r5C4(2)); 
inc; 

CALL  CuTSCHAP ( CP )  * 

CALL  3:JTSCHAP.(  L?  )  ! 

CALL  ITC5AD?ANC3(FLDES  )  > 

INC ;  /*  «'HILI  «/ 

/*  ''CDULF  */ 
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/*  FILE  PP.0C32 .SRC  IS  -AT  */ 

DDtSSMODULE:  DC! 

declare  i  bite; 

DECLARE  :?  LITIS  ALLY  '3DH  , 

L?  LITSEALLT  'JAH'! 

DECLARE  I  HTTII 

DiDLASE  CSUPP  BYT!  E ATA ( 33  ) ! 

DECLARE  ILDES  PTTE  0ATK44): 

rCT  AS  • 

-531(*5  BTTE  INITIAL  ('?30C*2.  INITIAL  ENTRT  INTO  FILTER 
'.5  02  ( * )  PTTE  INITIAL  l'?R0C»2.  ST*  IT  FOR  LATA  READY 
A3i3(*l  3TTS  INITIAL  ('??0C*2.  PERFORMING  FILTER  OSS  ION 
v504(*i  3TTI  INITIAL  i'PROCNE.  ADVANCE  CUTTER  SUPPRESS! 

ITCSA'ji'AITl!  PS3CEDJRE(2VC$  ID, AWAITED? VALUE)  EXTERNAL! 
DECLARE  EVCSID  3TTE , 

a^aited$?alje  *ord; 

END! 

ITC5 ADVANCE:  PROCEDURE! EVCS ID )  ETtERNAL! 

DECLARE  ZVC5IT  BTTE! 

END! 

JOTSCKAS:  PHOCEDiJHEICHAR) ! 

DICLASE  CHAR  BITE! 

DO  AHIL2  ! I NPUT! 0DAH)  AND  31H)  *  3!  END! 

OUTPUT ( 3DSE )  «  CHAR! 

INC! 

DLTSREX:  PROCiDtIREO)  5 
DECLAFE  3  BTTE! 

DECLARE  ASCII!*)  BTTE  DATA  (  'Z1234S578SA3CIEF ' ) ! 
DALL  DUT?CHAR( ASCII(3HR(B,4)  AND  0FH) )! 

CALL  OUTS CHAR ( ASC 1 1 ( 3  AND  3 FH ) ) ! 

END! 


3! 


DO  Z  -  3  TO  45! 

CALL  3vJTJCHAR(MS31(Z))! 
2ND! 

CALL  OOT?CSAR(CS): 

CALL  OOT5CHAR(Lf )! 

DO  3HILS  (I  <*  3PFH); 

DO  Z  *  3  TO  45! 

CALL  0UT»CEAR(MS32!Z) )! 
END! 

DALL  03T>CRAR(CR) ! 

dall  dutjchar! lf ) ; 

DALL  ITCSArf* IT1( FLOES , I ) ! 
1-1*1! 


DES ION 

ON  FRAME  *  '), 

ON  EVENTCOONT"' ! 
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to  z  =*  «.•  to  •*3; 

tall  ojtsckas(mso2(T)  ); 
ns; 
tall 

7 ALL  TOTSCKAPtOS]  ; 

TALL  :UT$CBAP.(L?;,* 

TO  l  *  0  TO  100; 

CALL  r:r£(250)? 

s«; 

TO  T  =  0  TO  45! 

TALL  00TSC“AP.O*?04(2)); 
i'10; 

CALL  OUTSCHAP ( CS ) ; 

CALL  0  JT$CHAP. ( L7 ) ; 

TALL  I?C$AD?AMCE(CSaPP); 

•NC;  /*  ih’ILi  */ 


MCI  /*TOOLT,2  */ 


EXAMPLE  #6  OUTPUT  ..I 


ENTERING  ITCJ INIT 
ENTERING  KERNELSINIT 
ENTERING  GETTORX 
SET  VP  TO  RUNNING!  VP  »  00 

S ELECTED SDBR  «  0550 

SITERING  UNLOCKVTM 
ENTERING  CHECKPREEMPT 
ENTERING  ITCSRETSVP 

RUNNINGS VPS ID  *  00 

ENTERING  I  T  C  S  A  W  A  I  T 

ENTERING  ITCSRETSVP 

RUNNINGSVPSID  *  00 

ENTSIING  I TCS LOCATE SEVC 
ENTERING  GE1WORX 
SET  VP  TO  RUNNING:  VP  »  01 

SELECT  ED  SDBR  >  0600 

ENTERING  UNLOCKVTM 
ENTERING  CHECKPREEMPT 
ENTERING  ITCSRETSVP 

RUNNINGSVPSID  »  01 

PROC#l .  INITIAL  ENTRY  INTO  CLUTTER  SUPPRESSION 
PROC# 1 .  WAIT  FOR  DATA  READY 

ENTERING  ITCSAWAIT 

ENTERING  ITCSRETSVP 

RUNNINGSVPSID  »  01 

ENTERING  ITCSLOCATESEVC 
ENTERING  GETWDRK 
SET  VP  TO  RUNNING!  VP  >  01 

SELECTED  SDBR  -  0600 

PROC# 1 .  PERFORMING  CLUTTER  SUPPRESSION:  FRAME  #  01 
PROC# 1 .  ADVANCE  FILTER  DESIGN  EVENTCOUNT 

ENTERING  ITCSADVANCE 

ENTERING  ITCSRETSVP 

RUNNINGSVPSID  *  01 

ENTERING  ITCSLOCATESEVC 

ENTERING  HARDWARES  INT 
ENTERING  GETWORK 
SET  VP  TO  RUNNING!  VP  »  01 

SELECTED SDBR  ■  0600 

PROC»l .  WAIT  FOR  DATA  READY 

ENTERING  ITCSAWAIT 

ENTERING  ITCSRETSVP 

RUNNINGSVPSID  ■  01 

ENTERING  ITCSLOCATESEVC 
ENTERING  GETWDRK 
SET  VP  TO  RUNNING!  VP  •  01 

SELECTS) SDBR  •  0600 

PROC# l  •  PERFORMING  CLUTTER  SUPPRESSION!  FRAME  #  02 
PROC#l.  ADVANCE  FILTER  DESIGN  EVENTCOUNT 


ENTERING  ITCSADVANCE 


EMERING  ITC$RET$VP 

RUNNINGS VPS  ID  *  01 

ENTERING  ITCS LOCATE SE VC 

ENTERING  HARDWARES  INT 
ENTERING  GETWORK 
SET  VP  TO  RUNNING:  VP  =  01 

S ELECTED SDBR  *  0600 

PROC* 1 .  WAIT  FOR  DATA  READY 

ENTERING  I  T  C  S  A  W  A  I  T 

ENTERING  ITCSRETSVP 

RUNNINGS VPS ID  =  01 

ENTERING  ITCSLOCATESEVC 
ENTERING  GETWORK 
SET  VP  TO  RUNNING:  VP  =  01 

S ELECTED  SDBR  =>  0600 

PROC»l.  PERFORMING  CLUTTER  SUPPRESSION:  FRAME  #.03 
PROC* 1 .  ADVANCE  FILTER  DESIGN  EVENTCOUNT 

ENTERING  ITCSADVANCE 

ENTERING  ITCSRETSVP 

RUNNINGS VPS  ID  »  01 

ENTERING  ITCSLOCATESEVC 

ENTERING  HARDWARES  INT 
ENTERING  GETWORK 
SET  VP  TO  RUNNING:  VP  »  01 

SELECTED  SDBR  »  0600 

PROC* 1 .  WAIT  FOR  DATA  READY 

ENTERING  ITCSAWAIT 

ENTERING  ITCSRETSVP 

RUNNINGS VPS ID  «  01 

ENTERING  ITCSLOCATESEVC 
ENTERING  GETWORK 
SET  VP  TO  RUNNING:  VP  -  01 

SELECTED SDBR  >  0600 

PROC* 1 .  PERFORMING  CLUTTER  SUPPRESSION:  FRAME  *  04 
PROC*l.  ADVANCE  FILTER  DESIGN  EVENTCOUNT 

ENTERING  ITCSADVANCE 

ENTERING  ITCSRETSVP 

RUNNINGS VPS  ID  »  01 

ENTERING  ITCSLOCATESEVC 

ENTERING  HARDWARES  INT 
ENTERING  GETWORK 
SET  VP  TO  RUNNING:  VP  >  01 

SELECTED  SDBR  -  0600 

PROC*l.  WAIT  FOR  DATA  READY 

OTTERING  ITCSAWAIT 

ENTERING  ITCSRETSVP 

RUNNINGS  VPS  ID  -  01 

ENTERING  ITCSLOCATESEVC 
ENTERING  GETWORK 
SET  VP  TO  RUNNING:  VP  «  01 

SELECTED  SDBR  «  0600 

PROC* 1 .  PERFORMING  CLUTTER  SUPPRESSION:  FRAME  ♦  05 
PROC* 1 .  ADVANCE  FILTER  DESIGN  EVENTCOUNT 
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I 


EXAMPLE  #6  OUTPUT  #2 


ENTERING  ITCSINIT 
ENTERING  KERNELS  IN IT 
ENTERING  GETWORK 
SET  VP  TO  RUNNING:  VP  »  04 

SELECTEDSDBR  =  0550 

ENTERING  UNLOCXVTM 
ENTERING  CHECKPREEMPT 
ENTERING  ITCSRETSVP 

RUNNINGSVPS ID  *  04 

ENTERING  I  T  C  S  A  W  A  I  T 

ENTERING  ITCSRETSVP 

RUNNINGSVPS ID  «  04 

ENTERING  ITCSLOCATESEVC 
ENTERING  GETWORK 
SET  VP  TO  RUNNING:  VP  «  05 

SELECTEDSDBR  »  0700 

ENTERING  UNLOCKVFM 
ENTERING  CHECKPREEMPT 
ENTERING  ITCSRETSVP 

RUNNINGSVPS ID  =  05 

PROC#Z.  INITIAL  ENTRY  INTO  FILTER  DESIGN 
PROC# 2.  WAIT  FOR  DATA  READY 

ENTERING  I  T  C  S  A  W  A  I  T 

ENTERING  ITCSRETSVP 

RUNNINGS  VPS  ID  *  05 

ENTERING  ITCSLOCATESEVC 
ENTERING  GETWORK 
SET  VP  TO  RUNNING:  VP  «  05 

SELECTEDSDBR  -  0700 

PROC # 2 .  PERFORMING  FILTER  DESIGN  ON  FRAME  #  01 
PROC# 2 .  ADVANCE  CLUTTER  SUPPRESSION  EVENTCOUNT 

ENTERING  ITCSADVANCE 

ENTERING  ITCSRETSVP 

RUNNINGSVPS ID  •  05 

ENTERING  ITCSLOCATESEVC 
ENTERING  CETWOKK 
SET  VP  TO  RUNNING:  VP  »  05 

SELECTEDSDBR  «  0700 

PROC# 2 .  WAIT  FOR  DATA  READY 

ENTERING  I  T  C  S  A  W  A  I  T 

ENTERING  ITCSRETSVP 

RUNNINGSVPS ID  *  05 

ENTERING  ITCSLOCATESEVC 
ENTERING  GETWORK 

SELECTEDSDBR  •  0500 

ENTERING  UNLOCXVTM 
ENTERING  CHECXPREEMPT 
ENTERING  ITCSRETSVP 

RUNNINGSVPS ID  ■  07 

ENTERING  GETCOUNTER 
ENTERING  UPDATECOUNTER 
ENTERING  UPDATECOUNTER 
ENTERING  UPDATECOUNTER 

ENTERING  UPDACTEECUNTER 


I 
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ENTERING  UPDATECOUNTER 

ENTERING  UPDATECOUNTER  ENTERING  LOCK"VP».t 
ENTERING  RDYTHI SVP 
ENTERING  ITCSRETSVP 

RUNNINGSVPSID  ’  07 

SET  VP  TO  READY:  VP  *  07 

ENTERING  GETOORK 
SET  VP  TO  RUNNING:  VP  »  05 

SELECTEDSDBR  »  0700 

PROC*Z .  PERFORMING  FILTER  DESIGN  ON  FRAME  ♦  02 
PROC* 2 .  ADVANCE  CLUTTER  SUPPRESSION  EVENTCOUNT 

ENTERING  ITCSADVANCE 

ENTERING  ITCSRETSVP 

RUNNINGSVPSID  «  05 

ENTERING  ITCSLOCATESEVC 
ENTERING  GETTORX 
SET  VP  TO  RUNNING:  VP  »  05 

SELECTEDSDBR  *  0700 

PROC# 2.  WAIT  FOR  DATA  READY 

ENTERING  I  T  C  S  A  W  A  I  T 

ENTERING  ITCSRETSVP 

RUNNINGSVPSID  *  05 

ENTERING  ITCSLOCATESEVC 
ENTERING  GETWDRK 

SELECTEDSDBR  «  0500 

ENTERING  UNLOCKVFM 
entering  CHECKPREEMPT 
ENTERING  ITCSRETSVP 

RUNNINGSVPSID  *  07 

entering  updateccwnter 
entering  updatecounter 
entering  updatecounter 
entering  updatecounter 
entering  updatecounter 
entering  updatecounter 
entering  loocvfm 

ENTERING  RDYTHI SVP 
ENTERING  ITCSRETSVP 

RUNNINGSVPSID  »  07 

SET  VP  TO  READY:  VP  *  07 

ENTERING  GETWORK 
SET  VP  TO  RUNNING:  VP  »  05 

SELECTEDSDBR  »  0700 

PROC* 2 .  PERFORMING  FILTER  DESIGN  ON  FRAME  *  03 
PROC* 2.  ADVANCE  CLUTTER  SUPPRESSION  EVENTCOUNT 

ENTERING  ITCSADVANCE 

ENTERING  ITCSRETSVP 

RUNNINGSVPSID  «  05 

ENTERING  ITCSLOCATESEVC 
ENTERING  GETWORK 
SET  VP  TO  RUNNING:  VP  »  05 

SELECTEDSDBR  ■  0700 

PROC* 2.  WAIT  FOR  DATA  READY 

ENTERING  I  T  C  S  A  W  A  I  T 

ENTERING  ITCSRETSVP 

RUNNINGSVPSID  *  05 

OTTERING  ITC$L0CAIE$EVC 


ENTERING  GETWCRK 

SELECT  S3  SDBR  =  0500 

ENTERING  UNLOCKVFM 
ENTERING  CHECKPREEMPT 
ENTERING  ITCSRETSVP 

RUNNINGSVPSID  >  07 

ENTERING  UPDATECOUNTER 
ENTERING  UPDATECOUNTER 
ENTERING  UPDATECOUNTER 
ENTERING  UPDATECOUNTER 
ENTERING  UPDATECOUNTER 
ENTERING  UPDATECOUNTER 
ENTERING  UPDATECOUNTER 
ENTERING  UPDAENTERING  LOCK  VIM 
ENTERING  RDYTHI SVP 
ENTERING  ITCSRETSVP 


RUNNINGSVPSID  * 

07 

SET  VP  TO  READY: 

VP  =■ 

07 

ENTERING  GETWORK 

SET  VP  TO  RUNNING: 

VP  . 

05 

SELECTED  SDBR  • 

0700 

PROCA2 .  PERFORMING  FILTER  DESIGN  ON  FRAME  *  04 
PROC»2.  ADVANCE  CLUTTER  SUPPRESSION  EVENTCOUNT 

ENTERING  ITCSADVANCE 

ENTERING  ITCSRETSVP 

RUNNINGSVPSID  «  05 

ENTERING  ITCS LOCATES ETC 
ENTERING  GETVK3RX 
SET  VP  TO  RUNNING:  VP  »  05 

S ELECTEE SDBR  *  0700 

PROC42 .  WAIT  FOR  DATA  READY 

ENTERING  I  T  C  S  A  W  A  t  T 

ENTERING  ITCSRETSVP 

RUNNINGSVPSID  »  05 

ENTERING  ITCSLOCATESEVC 
ENTERING  GETM3RX 

SELECTED  SDBR  •  0500 

ENTERING  UNLOCKVTM 
ENTERING  CHECKPREEMPT 
ENTERING  ITCSRETSVP 

RUNNINGSVPSID  *  07 

T 

ENTERING  UPDATECOUNTER 
ENTERING  UPDATECOUNTER 
ENTERING  UPDATECOUNTER 
ENTERING  UPDATECOUNTER 
ENTERING  UPDATECOUNTER 
ENTERING  UPDATECOUNTER 
ENTERING  UPDATECOUNTER 
ENTERING  UPDATECCUNTER 
ENTERING  LOCXVPM 
ENTERING  RDYTHI SVP 
ENTERING  ITCSRETSVP 

RUNNINGSVPSID  *  07 

SET  VP  TO  READY:  VP  »  07 

ENTERING  GETTORK 
SET  VP  TO  RUNNING:  VP  »  05 

SELECTED SDBR  »  0700 

PROC*2 .  PERFORMING  FILTER  DESIGN  ON  FRAME  ♦  05 
PROC#2.  ADVANCE  CLUTTER  SUPPRESSION  EVENTCOUNT 

ENTERING  ITC$ADVANCE 
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ENTERING  ITCSRETSVP 

RUNNINGSVPS ID  *  05 

ENTERING  ITCSLOCATESEVC 
ENTERING  GETWORK 
SET  VP  TO  RUNNING:  VP  *  05 

SELECTEDSDBR  *  0700 

PROC#2.  WAIT  FOR  DATA  READY 

ENTERING  I  T  C  S  A  W  A  I  T 

ENTERING  ITCSRETSVP 

RUNNINGS VPS  ID  »  05 

ENTERING  ITCSLOCATESEVC 
ENTERING  GETWORK 

SELECTEDSDBR  »  0500 

ENTERING  UNLOCXV™ 

ENTERING  CHECKPREEMPT 
ENTERING  ITCSRETSVP 

RUNNINGSVPSID  »  07 

ENTERING  UPDATECOUNTER 
ENTERING  UPDATECOUNTER 
ENTERING  UPDATECOUNTER 
ENTERING  UPDATECOUNTER 
ENTERING  UPDATECOUNTER 
ENTERING  UPDATECOUNTER 
ENTERING  UPDATECOUNTER 
ENTERING  UPDATECOUNTER 
ENTERING  UPDATECOUNTER 
ENTERING  UPDATECOUNTER 

ENTERING  UPDATBCOUNTERENTER ING  LOCKVPM 
ENTERING  RDYTHISVP 
ENTERING  ITCSRETSVP 

RUNNINGSVPSID  *  07 

SET  VP  TO  READY:  VP  .  07 

ENTERING  GETWORK 
SET  VP  TO  RUNNING:  VP  .  OS 

SELECTEDSDBR  »  0700 

PROC»2.  PERFORMING  FILTER  DESIGN  ON  FRAME  ♦  06 
PROC#Z.  ADVANCE  CLUTTER  SUPPRESSION  EVENTCOUNT 

ENTERING  ITCSADVANCE 

ENTERING  ITCSRETSVP 

RUNNINGSVPSID  •  05 

ENTERING  ITCSLOCATESEVC 
ENTERING  GETWORK 
SET  VP  TO  RUNNING:  VP  .  05 

SELECTEDSDBR  *  0700 

PROC#2.  WAIT  FOR  DATA  READY 

ENTERIN'"  I  T  C  S  A  W  A  I  T 

ENTERING  ITCSRETSVP 

RUNNINGSVPSID  •  05 

ENTERING  ITCSLOCATESEVC 
ENTERING  GETWORK 

SELECTEDSDBR  «  0500 

ENTERING  UNUOCKVTW 
ENTERING  CHECKPREEMPT 
ENTERING  ITCSRETSVP 

RUNNINGSVPSID  *  07 

ENTERING  UPDATECOUNTER 
ENTERING  UPDATECOUNTER 

OTTERING  updmecounter 
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ENTERING  UPDATECOUNTER 
ENTERING  UPDATECOUNTER 
ENTERING  UPDATECOUNTER 
ENTERING  UPDATECOUNTER 
ENTERING  UPDATECOUNTER 
ENTERING  UPDATECOUNTER 
ENTERING  UPDATECOUNTER 
ENTERING  UPDATECOUNTER 
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